Objective-C Fundamentals

Responding to low-memory warnings
197
original view in memory and simply reuses it when the user returns to it (you could
handle the viewDidAppear message if you needed to perform an action each time the
view becomes visible to the user).
By comparison, if you switch to the second tab and then simulate a low-memory situation,
the debugger should break in FirstViewController’s viewDidUnload method,
indicating the view controller has decided it can help resolve the low-memory situation
by deallocating the view that’s currently invisible to the user.
Once the root view has been unloaded, you can continue using the application
with no obvious difference in behavior. The next time you return to the first tab, you
should notice that your viewDidLoad implementation is automatically invoked in
order to reinitialize the view that the framework has just reloaded from your NIB file.
Knowing that a view can suddenly and perhaps unexpectedly become deallocated,
you should be careful not to store important application state in the view. Apart from
breaking the model-view-controller design pattern principles, it won’t work reliably. As
an example, if you use the enabled state of a UIButton or a selected item in a
UITableView to control the logic or behavior of your application, you may notice your
application enters an unexpected state when the view becomes deallocated and then
re-created, causing all of the controls to return to the state in which they were
declared in the NIB file.
In general, the correct place for view initialization logic is in the viewDidLoad
method. This logic is invoked whenever the view associated with the view controller is
constructed. If you take a look at RootViewController’s viewDidLoad method implementation
within the Rental Manager application, you’ll notice this is exactly where
the cityMappings dictionary is created, ensuring it’s also re-created if it’s destroyed
due to a low-memory situation.
As an extension to this rule of thumb, you may also like to override the matching
viewDidUnload message as an ideal place to save application state just before the view
is removed from memory.
9.6.3 Observing the
UIApplicationDidReceiveMemoryWarningNotification
Sometimes when writing a support class deep in your application logic, it may be
inconvenient for a view controller or application delegate to be responsible for freeing
any associated resources in a low-memory situation. For one thing, doing so would
break encapsulation, as something external to the class would require knowledge of
and access to its internals in order to free them. For such situations, Cocoa Touch provides
an alternative solution via a feature called notifications.
A notification allows a class to respond to an event, such as a low-memory situation,
no matter where the class is positioned in the application; it no longer needs to be a
UIViewController subclass. In general, an object called the sender will generate a
notification and dispatch it to be received by zero or more objects called observers.
The glue that connects notification senders with observers is a class called
NSNotificationCenter. This class provides a mechanism for senders to broadcast