Programming iOS 4

Instance Visibility

The problem of communication often comes down to one object being able to see another: Object Manny needs to be able to find Object Jack repeatedly and reliably over the long term so as to be able to send Jack messages. (This is the same problem I spoke of in Chapter 2 as getting a reference to an object.)

An obvious solution is an instance variable of Manny whose value is Jack. This is appropriate particularly when Manny and Jack share certain responsibilities or supplement one another’s functionality, and when they will both persist, especially when they will both persist together. A controller whose job is to configure and direct a certain view will need to exist just as long as the view does; they go together. The application object and its delegate, a table view and its data source, a UIViewController and its UIView — these are cases where the former must have an instance variable pointing at the latter.

With instance variables comes the question of memory management policy. Should Manny, which has an instance variable pointing to Jack, also retain Jack? Basically, it depends on how closely allied the objects are. An object does not typically retain its delegate or its data source; it can exist without a delegate or a data source, and the delegate and data source have lives of their own — it is none of this object’s business to say whether the delegate or data source should be allowed to go out of existence. This object is therefore always prepared for the ...