Objective-C Fundamentals

196 CHAPTER 9 Memory management
view". If you refer back to chapter 1, you’ll notice that the CoinTossViewController
class implemented viewDidUnload as follows:
- (void)viewDidUnload {
self.status = nil;
self.result = nil;
}
These statements, which were not discussed at the time, ensure that when the view
controller receives a didReceiveMemoryWarning message and decides to release the
view, the two UILabel controls are also released. As a rule of thumb, any subview or
control that’s retained by an ivar or property in the view controller class should be
released whenever the viewDidUnload message is received.
Correct memory management requires careful attention to detail
As mentioned in the sidebar “Danger, Will Robinson, here be sleeping dragons” in
chapter 5, it’s important to note the difference between the following three statements:
[status release]; status = nil; self.status = nil;
The first statement sends the object pointed to via the status instance variable a
release message, hopefully freeing its associated resources. The statement doesn’t
alter the value of the status variable, leaving it to point to the now nonexistent object.
The second statement attempts to resolve this by setting the variable to nil. Doing
this doesn’t send the object a release message, and hence the UILabel control will
never be deallocated even though you’ve lost the ability to refer to it.
The last statement (and its logical equivalent [self setStatus:nil]) performs
both tasks by invoking the setter method associated with the status property. From
chapter 5, remember that a property with the retain attribute specified automatically
sends a release message to its old value when the property is being set to a
new value, such as the nil specified here.
Knowing that a UIViewController could decide to deallocate its view and re-create it
when next required can have important implications for where you can place initialization
logic or store application state. Get it wrong, and the application may appear
to behave correctly during development, only to fail the first time your customer sees
a low-memory situation develop.
To see this process in action, create a new iPhone application using the Tab Bar
Application template and uncomment the source code for the viewDidLoad method
within the FirstViewController class. Then add a breakpoint to the beginning of the
viewDidLoad and viewDidUnload methods.
When you launch the application, you should see that viewDidLoad is immediately
called to initialize the UI controls loaded from the FirstView NIB file.
If you switch to the second tab and then return to the first, you shouldn’t notice
any additional breakpoints being hit. This is because the UIKit framework keeps the