Question

Having worked through some tutorials on some basics via the iPhone, I’m struggling to determine how best to structure my code. The book I’m using points out things like “you wouldn’t normally put this here, but for expediency…”. Well, I’d like to know what one would “normally” do.

My application is somewhat simple – there is a table view showing a list of objects and one can add, remove, edit these objects (I plan to provide a more sophisticated organizational scheme later, but I’m keeping it simple to get something working).

So, I have a RootViewController that extends UITableViewController. When the “add” button is clicked I push a subclass of UIViewController onto the stack (this class is the “add/edit” form for my objects). I have a simple data structure-style class to hold the fields of the objects.

The apps like this in the book basically put an array inside the RootViewController and use a reference to the model class to represent the “object being edited”. Basically, the models are all wrapped up in the view controllers. This seems wrong.

So, my question is: where do the models and the objects for managing them normally live?

And, does the answer to this depend on how I’m storing my objects? I have not done much with CoreData, though my plan was to use it for persistence of my objects. Will the hooks and boilerplate provided by XCode make this a nonissue?

Best answers will be pointers to some best practices type stuff, which I wasn’t able to easily find via Google or on Apple’s Dev site.

Answer 1

First of all you are right about your intuition that it seems wrong. As you described the model is stored in the view controllers. That is a bad idea. By doing so you are violating the model-view-controller paradigm, which makes your code hard to maintain.

So what you need to do now is get your model in a separate object or tree of objects or even better use CoreData, which is also great in terms of memory management.

As you want to use CoreData you should have a look at the UIFetchedResultsController class which you will use to obtain the objects from the managedObjectContext which will be your model.

What you would do in your table view – detail edit example is:

1. Fetch the contents of the table view using a fetch request and setting it on the NSFetchedResultsController you hold as an instance variable in the rootViewController
2. Set this rootViewController as the delegate of that NSFetchedResultsController
3. If an item is checked or the add button is pressed push your detail view controller on the stack, pass the object to be edited with it, or nil if it is a new object. Also pass the managedObjectContext to the detailViewController. Update or create the object.
4. Implement the delegate methods of NSFetchedResultsController in your rootViewController and there you reload the contents of the table when necessary.

What you gain is a nice and clear separation of model (CoreData’s managedObjectContext) the controller (rootViewController and detailViewController) and you views. If you now edit an entry by using the detail view, your rootViewController is notified via your NSFetchedResultsController and automatically updated. What you also gain is that you do not have a strong reference among the viewControllers in your application.

Btw, you set up your CoreData stuff in the application’s delegate. There is a lot of boilerplate code around in Xcode and on the ADC. Check out the Recipies app [1] in which this approach I just descriped is used. There are also some videos about CoreData on Apple’s developers site.

[1]: http://developer.apple.com/iphone/library/samplecode/iPhoneCoreDataRecipes/Introduction/Intro.html CoreDataRecipies