Programming iOS 4

Chapter 19. View Controllers

An iOS app’s interface is dynamic in a way that a Mac OS X application is not. In Mac OS X, 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, which in the case of the iPhone is almost forbiddingly tiny. The iOS solution to this is to replace interface with interface, as needed. Thus, entire screens of material need to come and go in a fashion that is not only agile but intuitive: the user must not be confused. Management of this task resides in a view controller (an instance of a UIViewController subclass).

You are extremely unlikely to write an iOS app that hasn’t at least one view controller. They are, not to put too fine a point on it, indispensable. In this regard, the Empty Window example project that we’ve been using in earlier chapters to demonstrate individual views and controls is artificial and exceptional. Even if your app’s interface as a whole is never replaced by some other interface, you are still likely to use a view controller, because a view controller also knows how to rotate the interface in response to the user rotating the device.

A view controller manages a single view (which can, of course, have subviews); its view property points to the view it manages. The view has no explicit pointer to the view controller that manages it, but a view controller is a UIResponder and is in the responder chain just above its ...