About Windows, Views, and Controls

Like Mac OS X, iOS uses windows and views to present graphical content on the screen. Although there are many similarities between the window and view objects on both platforms, the roles played by both windows and views differ slightly on each platform.

The Role of UIWindow

In contrast with Mac OS X applications, iPhone applications typically have only one window, represented by an instance of the UIWindow class. Your application creates this window at launch time (or loads it from a nib file), adds one or more views to it, and displays it. After that, you rarely need to refer to the window object again.

In iOS, a window object has no visual adornments such as a close box or title bar and cannot be closed or manipulated directly by the user. All manipulations to a window occur through its programmatic interfaces. The application also uses the window to facilitate the delivery of events to your application. For example, the window object keeps track of its current first responder object and dispatches events to it when asked to do so by the UIApplication object.

One thing that experienced Mac OS X developers may find unusual about the UIWindow class is its inheritance. In Mac OS X, the parent class of NSWindow is NSResponder. In iOS, the parent class of UIWindow is UIView. Thus, in iOS, a window is also a view object. Despite its parentage, you typically treat windows in iOS the same as you would in Mac OS X. That is, you typically do not manipulate the view-related properties of a UIWindow object directly.

When creating your application window, you should always set its initial frame size to fill the entire screen. If you load your window from a nib file, Interface Builder does not permit you to create a window smaller than the screen size. If you create your window programmatically, however, you must specifically pass in the desired frame rectangle at creation time. There is no reason to pass in any rectangle other than the screen rectangle, which you can get from the UIScreen object as shown here:

UIWindow* aWindow = [[[UIWindow alloc] initWithFrame:[[UIScreen mainScreen] bounds]] autorelease];

Although iOS supports layering windows on top of each other, your application should never create more than one window. The system itself uses additional windows to display the system status bar, important alerts, and other types of messages on top of your application’s windows. If you want to display alerts on top of your content, use the alert views provided by UIKit rather than creating additional windows.

The Role of UIView

A view, an instance of the UIView class, defines a rectangular area on the screen. In iPhone applications, views play a key role in both presenting your interface and responding to interactions with that interface. Each view object has the responsibility of rendering content within its rectangular area and for responding to touch events in that area. This dual behavior means that views are the primary mechanism for interacting with the user in your application. In a Model-View-Controller application, view objects are the View portion of the application.

In addition to displaying its own contents and handling events, a view may also manage one or more subviews. A subview is simply a view object embedded inside the frame of the original view object, which is referred to as the parent view or superview. Views arranged in this manner form what is known as a view hierarchy and may contain any number of views. Views can also be nested at arbitrarily deep levels by adding subviews to subviews. The organization of views inside the view hierarchy controls what appears on screen, as each subview is displayed on top of its parent view. The organization also controls how the views react to events and changes. Each parent view is responsible for managing its direct subviews, by adjusting their position and size as needed and even responding to events that its subviews do not handle.

Because view objects are the main way your application interacts with the user, they have a number of responsibilities. Here are just a few:

• Drawing and animation

  • Views draw content in their rectangular area.

  • Some view properties can be animated to new values.

• Layout and subview management

  • Views manage a list of subviews.

  • Views define their own resizing behaviors in relation to their parent view.

  • Views can manually change the size and position of their subviews as needed.

  • Views can convert points in their coordinate system to the coordinate systems of other views or the window.

• Event handling

  • Views receive touch events.

  • Views participate in the responder chain.

In iPhone applications, views work closely with view controllers to manage several aspects of the views’ behavior. View controllers handle the loading and unloading of views, interface rotations caused by the user physically rotating the device, and interactions with the high-level navigation objects used to construct complex user interfaces. For more information, see “The Role of View Controllers.”

UIKit View Classes

The UIView class defines the basic properties of a view but not its visual representation. Instead, UIKit uses subclasses to define the specific appearance and behavior for standard system elements such as text fields, buttons, and toolbars. Figure I-1 shows the class hierarchy diagram for all of the views in UIKit. With the exception of the UIView and UIControl classes, most of the views in this hierarchy are designed to be used as-is or in conjunction with a delegate object.

Figure I-1  View class hierarchy

This view hierarchy can be broken down into the following broad categories:

• Containers

  Container views enhance the function of other views or provide additional visual separation of the content. For example, the UIScrollView class is used to display views whose contents are too large to fit onscreen all at once. The UITableView class is a subclass of UIScrollView that manages lists of data. Because table rows are selectable, tables are commonly used for hierarchical navigation too‚Äîfor example, to drill down into a hierarchy of objects.

  A UIToolbar object is a special type of container that visually groups one or more button-like items. A toolbar typically appears along the bottom of the screen. The Safari, Mail, and Photos applications all use toolbars to display buttons representing frequently used commands. Toolbars can be shown all the time or only as needed by the application.

• Controls

  Controls are used to create most of a typical application‚Äôs user interface. A control is a special type of view that inherits from the UIControl superclass. Controls typically display a specific value and handle all of the user interactions required to modify that value. Controls also use standard system paradigms, such as target-action and delegation, to notify your application when user interactions occur. Controls include buttons, text fields, sliders, and switches.

• Display views

  Although controls and many other types of views provide interactive behavior, some views simply display information. The UIKit classes that exhibit this behavior include UIImageView, UILabel, UIProgressView, and UIActivityIndicatorView.

• Text and web views

  Text and web views provide a more sophisticated way to display multiline text content in your application. The UITextView class supports the display and editing of multiple lines of text in a scrollable area. The UIWebView class provides a way to display HTML content, which lets you incorporate graphics and advanced text-formatting options and lay out your content in custom ways.

• Alert views and action sheets

  Alert views and action sheets are used to get the user‚Äôs attention immediately. They present a message to the user, along with one or more optional buttons that the user can use to respond to the message. Alert views and action sheets are similar in function but look and behave differently. For example, the UIAlertView class displays a blue alert box that pops up on the screen and the UIActionSheet class displays a box that slides in from the bottom of the screen.

• Navigation views

  Tab bars and navigation bars work in conjunction with view controllers to provide tools for navigating from one screen of your user interface to another. You typically do not create UITabBar and UINavigationBar items directly but configure them through the appropriate controller interface or using Interface Builder instead.

• The window

  A window provides a surface for drawing content and is the root container for all other views. There is typically only one window per application. For more information, see “The Role of UIWindow.”

The Role of View Controllers

Applications running in iOS have many options for organizing their content and presenting it to the user. An application that contains a lot of content might divide that content up into multiple screens’ worth of information. At runtime, each screen would then be backed by a set of view objects responsible for displaying the data for that particular screen. The views for a single screen would themselves be backed by a view controller object, whose job is to manage the data displayed by those views and coordinate updates with the rest of the application.

The UIViewController class is responsible for creating the set of views it manages and for flushing them from memory during low-memory situations. View controllers also provide automatic responses for some standard system behaviors. For example, in response to a change in the device's orientation, the view controller can resize its managed views to fit the new orientation, if that orientation is supported. You can also use view controllers to display new views modally on top of the current view.

In addition to the base UIViewController class, UIKit includes more advanced subclasses for handling some of the sophisticated interface behaviors common to the platform. In particular, navigation controllers manage the display of multiple hierarchical screens worth of content. Tab bar controllers let the user switch between different sets of screens, each of which represents a different operating mode for the application.

For information on how to use view controllers to manage the views in your user interface, see View Controller Programming Guide for iOS.

Organization of This Document

This document contains the following chapters:

• ‚ÄúWindows and Views‚Äù provides an overview of the window and view architecture used in iOS.

• ‚ÄúGraphics and Drawing‚Äù describes the drawing model used by views to render content to the screen.