Programming iOS 5, 2nd Edition

Chapter 19. View Controllers

An iOS app’s interface is dynamic, and with good reason. On the desktop, an application’s windows can be big, and there can be more than one of them, so there’s room for lots of interface. With iOS, everything needs to fit on a single display consisting of a single window, which in the case of the iPhone is almost forbiddingly tiny. The iOS solution to this is to swap out interface and replace it with other interface, as needed. Thus, entire regions of interface material — often the entire contents of the screen — must come and go in an agile fashion that is understandable to the user. Animation is often used to emphasize and clarify the replacement of one view by another.

Management of this task resides in a view controller, an instance of UIViewController. Actually, a view controller is most likely to be an instance of a UIViewController subclass. The UIViewController class is designed to be subclassed. You are very unlikely to use a plain vanilla UIViewController object. You might write your own UIViewController subclass, or you might use a built-in UIViewController subclass such as UINavigationController or UITabBarController. On the other hand, you will generally not subclass a built-in UIViewController subclass such as UINavigationController or UITabBarController, unless specifically instructed by the documentation to do so. You’ll either use a built-in UIViewController subclass as is, or you’ll subclass UIViewController yourself. (The major exception ...