Question

In AppKit we have “representedObject” available through NSViewController, this representedObject is generally set to ModelController or the model which the NSViewController displays, this works great with bindings as you just set the new representedObject and model details are updated in the view, BUT in case of iPhone (UIKit, with NO Cocoa bindings available), there is no such representedObject in UIViewController so here are few things I am interested in knowing:-

1. What is the best/recommended way of binding the model to the UIViewController?, preferably dont want to maintain lot of IBOutlets and calls setters to updated the changed model data for display in view.
2. How/When should the related model of the UIViewController be released?
3. When is the -[UIViewController dealloc] called, in the typical iPhone application.

Am looking for architecting some classes so that the UIViewController coordinates between the view and the model, but at the same time, deallocs the model when ever not necessary.

TIA.

Answer 1

That’s the big problem with Cocoa bindings, it hides a lot of things that are very easy.

dealloc is called when the retain count reaches 0. For a view controller that will happen when other controllers have released it and it doesn’t have any other retains. You shouldn’t worry about this if you are doing memory management according to the rules.

Create a property for your model object, or model controller if you want to go to that level of abstraction. Using the property correctly (like always using self.model for receiving assignments), and release the object in your dealloc implementation, and set it to nil in viewWillUnload. Properties create the accessors for you.

As for releasing your model when not required, the above will handle that for you – there’s no need to overthink it. If you are creating massive data structures, then you can consider building them in viewWillAppear and tearing down in viewWillDisappear in addition to the above.

You will need more outlets and glue code than you would with bindings; but you’ll have to write a lot less code to manage your bindings. Remember that iPhone is supposed to be a less powerful device, and you are supposed to take greater care of resources – and the UIViewController api gives you the opportunities to do that.