UIViewController

An iOS application has exactly one window. (Mac apps may have many). The window is a subclass of UIView, so it can contain other views, and it is perfectly reasonable to write an app that creates its views and adds them directly to the window.

However, views often occur in groups, and it is convenient to make them all appear, disappear, move, become transparent and so forth, as a group. Also, when the device rotates you may want to move or resize some of the subviews.

For these and other reasons there exists the UIViewController class. You write custom view controllers as needed. For special purposes there are defined subclasses of UIViewController like UITableViewController and UINavigationController.

Calling these things view controllers is somewhat misleading. They are not controllers in the sense of the Model-View-Controller paradigm. They are not visible, and they don't usually control any part of the model. It might be better to call them view administrators.

A view controller owns one view. All the views it controls are subviews of this one. When the view controller is created it may or may not create its view. The process is diagrammed here.

One job of a view controller is to respond to requests from the system when memory becomes tight. The view controller will unload a view that is not needed. It will be rebuilt later on demand. That process is diagrammed here.

The View Controller Programming Guide.

The page was last updated Saturday, November 5, 2011 10:24 PM