iOS iPhone Contacts App and Delegates

The favorites are probably stored in a SQLite database. That database is then queried to populate the favorites view.

In general all iPhone apps should follow MVC design. So you update the Model when the favourites change: this has nothing to do with the views. When the View will be displayed it's Controller will check the Model and update the view. So when you go back to the favourites screen the Controller for that table view simply queries the Model.

You need to separate out your model from your controllers and certainly from your views.

nashyo said:

I understand MVC, but I don't understand how you can update the model. I guess I need to read about SQLite ?

Click to expand...

MVC's more of a conceptual thing —*there's tons of ways you can update your model. For instance, if you didn't care about saving your contacts to disk (which is a simplification in order to make this explanation shorter) you could do this:

1. Your app delegate, in applicationDidFinishLaunching, creates a NSMutableArray. This array will hold favourites. This array is your model.
2. On every view controller subclass you make, give it a property like so:
   
   Code:

   @property (nonatomic, strong) NSMutableArray *favourites;

3. Whenever you instantiate a view controller, pass in the favourites array. So, for the root view controller, when you're creating it in the app delegate (in applicationDidFinishLaunching), set its favourites array to the array you created in step 1.
4. Now, all the view controllers are sharing the same model. All you need to do to get the automatic refreshing is, in each view controller, override viewWillAppear and do whatever you do to refresh your data (so if it's a table view controller, call [tableView reloadData].

So, that's a very basic MVC design. If you wanted to add loading and saving to that design, you would write the array to a file in the applicationWillResignActive method of your app delegate, and make sure to load that file in applicationDidFinishLaunching.

Using sqlite would be another valid MVC design. It's probably a better one overall: I used this example because it was quicker to explain. Basically, the point I'm trying to get across is that there's a whole lot of different ways you can implement MVC, and it depends on your particular circumstances which one is best.

nashyo said:

http://imageshack.us/photo/my-images/88/capturejx.jpg/

So effectively, your passing a common instance of NSMutableArray *favorites around, that is never deallocated (check my pic).

Would you use the prepareForSegueMethod to pass an object like this?

Click to expand...

Yeah, in the example I proposed then that's what's going on.

I haven't actually used storyboards myself, so I can't say for definite that that's where to do it: I tend to create my view controllers manually in code. But it sounds like the right place.

nashyo said:

So effectively, your passing a common instance of NSMutableArray *favorites around, that is never deallocated (check my pic).

Click to expand...

That's one option. Or you could use a provided singleton like NSUserDefaults. Or you could have your own singleton that abstracts the detail of how/where the data is persisted. There are lots of options. The job of the programmer is to choose the correct one.

Read up on Core Data as well. It is a very powerful framework. You can populate UITableViews with a fetch controller. So you would setup your fetch query to get all contacts from your model where the favorite flag was checked and your table view would use this to populate its data. So when you loaded the table view or called reload it would show your latest favorites.

There is so much support for core data that I don't see a good reason to use SQLite unless you have existing code you want to reuse.