Working with Windows and Views in iPad Apps
iPad apps have a single window, so you won’t find additional document windows for displaying content. When your application is running — even though other apps may be hibernating or running in the background — your app’s interface takes over the entire screen.
The iOS Window
The single window that you see displayed on the iPad or iPhone is an instance of the UIWindow class. This window is created at launch time, either programmatically by you or automatically by UIKit when you use a storyboard. In general, after you create the Window object (that is, if you create it instead of having it done for you), you never really have to think about it again.
A user can’t directly close or manipulate an iOS window. It’s your app that programmatically manages the window.
Although your application never creates more than one window at a time, iOS can support additional windows on top of your window. The system status bar is one example. You can also display alerts on top of your window by using the supplied Alert views.
The iOS View
In an iOS app world, view objects are responsible for the view functionality in the Model-View-Controller architecture. A view is a rectangular area on the screen (on top of a window).
In the UIKit framework, windows are really a special kind of view, but for the purpose of this discussion, views sit on top of the window.
What views do
Views are the main way for your app to interact with a user. This interaction happens in two ways:
Views display content. This happens, for example, by making drawing and animation happen onscreen. In essence, the view object displays the data from the model object.
Views handle touch events. Views respond when the user touches a button, for example. Handling touch events is part of a responder chain.
The view hierarchy
Views and subviews create a view hierarchy. You have two ways of looking at it (no pun intended this time): visually (how the user perceives it) and programmatically (how you create it). You must be clear about the differences or you’ll find yourself in a state of confusion that resembles the subway at rush hour.
Looking at it visually, the window is at the base of this hierarchy with a Content view on top of it (a transparent view that fills the window’s Content rectangle). The Content view displays information as well as allowing the user to interact with the application, using (preferably standard) user-interface items such as text fields, buttons, toolbars, and tables.
In your program, that relationship is different. The Content view is added to the window view as a subview. But the Content view can also have its own subviews, and so on. Possible relationships include:
Views added to the Content view become subviews of it.
Views added to the Content view become the superviews of any views added to them.
A view can have one (and only one) superview and zero or more subviews.
It seems counterintuitive, but a subview is displayed on top of its parent view (that is, on top of its superview). Think about this relationship as containment: A superview contains its subviews. This figure shows an example of a view hierarchy.
Controls — such as buttons, text fields, and so on — are actually view subclasses that become subviews. So are any other display areas that you may specify. The view must manage its subviews, as well as resize itself with respect to its superviews. Fortunately, much of what the view must do is already coded for you. The UIKit framework supplies the code that defines view behavior.
The view hierarchy also plays a key role in both drawing and event handling.
You create or modify a view hierarchy whenever you add a view to another view, either programmatically or with the help of the Interface Builder. The UIKit framework automatically handles the relationships associated with the view hierarchy.
Developers typically gloss over this visual-versus-programmatic-view-hierarchy stuff when starting out — and without understanding these concepts, it’s really difficult to get a handle on what’s going on.