Getting Started with Interface Builder - Xcode 4 - page 144

Using nib files
Manual nib loading is similar to automatic nib loading, with the difference that objects defined in a nib can be
loaded and flushed from memory as needed, using a variety of standard loading methods. This is called lazy
loading and is a standard Apple technique used to minimize an application's memory footprint.
It's especially critical for iOS apps, which have to work with very limited memory. View swapping is a related
iOS technique that relies on lazy loading. When the user selects a new view by swiping a finger or selecting it
from a navigation control (a tab bar, navigation controller, or button), the code loads a new view from a nib file,
displays it, and deletes the old view from memory.
The swap can be animated as a special effect. The UIViewController and UIView classes include meth-
ods that create simple animations and delete the old view automatically. For more advanced effects, you can cre-
ate more complex animations with custom code and delete the view manually.
The view-based application template is a good starting point for view swapping, but it has some quirks and
subtleties that can make it difficult to understand. In outline, it works like this:
Every application has an instance of UIWindow , which is the main app window. This is loaded when
the application boots and isn't usually modified. This window object is included in the MainWin-
dow.xib file.
A UIViewController object is included in the same nib file, together with the UIWindow object.
The UIViewController includes a placeholder for a separate UIView nib file, which also is loaded
automatically when the application starts. This placeholder points to a separate nib file, which is called
<appName>ViewController.xib .
The UIViewController is subclassed to include code features that manage the UI. The UIView ob-
ject also may be subclassed to create specialized graphics.
When the user requests a view swap by tapping a navigation object such as a toolbar or navigation bar
item, a new view controller is loaded from a nib file. The UIView linked to the new controller is swapped
into the view property of the original view controller. The old view is released from memory. The swap
may be animated.
There are now two view controllers and one view loaded in memory. The new view controller manages
UI interaction for the new view, which draws the contents of the window. The old view controller remains
in place and is used to manage further swap events.
The last two steps are repeated whenever a new view is requested.
Figure 7.1 shows the initial nib hierarchy. Bafflingly, the appViewController.xib doesn't include a view
controller object. Instead, it includes a view object that is loaded by the view controller. In IB-speak, the view
controller owns its nib file. It isn't created by it.
But the mainWindow.xib ile does include a window object. This isn't a logical arrangement, but it's how
view-based iOS apps are constructed. It's difficult to use IB effectively unless you take the time to understand it.
FIGURE 7.1
The initial nib hierarchy of an iOS view-based application