Objective-C Fundamentals

Responding to low-memory warnings
195
}
cityMappings = nil;
In this implementation, when the operating system requests additional memory to be
freed, the RootViewController class releases the city mapping NSDictionary. This
frees memory immediately, but before you next need to look up an image to display
for a given city, you’ll have to re-create the dictionary and its contents. You’ll see how
this scenario is handled by the existing source code in a minute, but let’s first investigate
the implications of a comment inserted by the iPhone project templates.
If you create a new project in Xcode and select the Navigation-based Application
template, you may notice that it provides an override for the didReceiveMemoryWarning
method. This default implementation doesn’t perform any additional functionality. It
simply forwards the message onto the UIViewController superclass, but it does
include a comment hinting at an important fact to remember. This comment and a
related one in the viewDidUnload method are repeated here:
didReceiveMemoryWarning
// Releases the view if it doesn't have a superview.
viewDidUnload
// Release any retained subviews of the main view.
// e.g. self.myOutlet = nil;
These comments hint that the UIKit framework will cache views that are currently offscreen,
such as when the user temporarily switches to another tab in a tab bar application
or drills down to another view in a navigation-based application.
When a view controller is initialized, it loads the associated view from a NIB file (or
creates it from scratch via code). Once loaded, the view controller keeps the user
interface controls in memory even if the view is temporarily moved offscreen.
Keeping the view in memory is efficient from a performance perspective because it
allows the view to be redisplayed without repeating the construction process, but it
comes with a potential negative in the form of increased memory consumption. This
is especially true if you have a deep hierarchy in a navigation-based UI or if you have
many tabs with complex UI requirements that will cause a number of offscreen views
to be cached.
The UIKit framework is designed to cope with this scenario. It automatically
changes its view-caching behavior whenever your application finds itself in a lowmemory
situation. When a UIViewController receives a didReceiveMemoryWarning
message, and the view it controls is currently offscreen (it doesn’t have a superview, or
parent), the UIViewController sends the view a release message. In most cases, this
is enough to cause the view to immediately become deallocated, and hence this feature
reduces the amount of memory consumed by the application without affecting
the visual appearance or behavior of what the user can currently see or interact with.
This memory optimization, however, can be undone if your view controller keeps
objects in the view alive because they haven’t yet been released. This is what is hinted
at by the comment in viewDidUnload: "Release any retained subviews of the main