Go to---window and view schema Introduction!

Windows and Views

Windows and views are visual components that construct the user interface for iphone applications. The window provides a background platform for content display, while the view is responsible for most of the content mapping and is responsible for responding to user interactions. Although the concepts discussed in this chapter are associated with Windows and views, the discussion process is more focused on the view because the view is more important to the system.

Views are so important to the iphone application that it is impossible to discuss all aspects of the view in one chapter. This chapter focuses on the basic properties of Windows and views, the relationships between attributes, and how these properties are created and manipulated in your application. This chapter does not discuss how views respond to touch events or how to draw custom content, and for more information about those topics, see the event handling and graphics and painting sections, respectively.

What are windows and views?

Like Mac OS X, the IPhone OS displays graphical content on the screen through windows and views. Although there are a lot of similarities between window and view objects on two platforms, there are slight differences in the effect on each platform.

The role of UIWindow

The

and Mac OS x applications differ, and the iphone app typically has only one window, represented as an instance of a UIWindow class. Your application creates this window at startup (or from a nib file), and adds one or more views to the window and then displays it. After the window is displayed, you seldom need to refer to it again.

in the iphone OS, the Window object does not have visual decorations like a close box or title bar, and the user cannot directly close or otherwise manipulate it. All operations on a window need to be implemented through its programming interface. An application can use a Window object for event delivery. The Window object keeps track of the current first responder object and passes the event when the UIApplication object requests it.

There is one more thing that might make an experienced Mac OS x developer wonder about the inheritance of the UIWindow class. In Mac OS X, the parent class of Nswindow is Nsresponder, whereas in iphone OS, UIWindow's parent class is UIView. Therefore, the window is also a View object in the iphone OS. Regardless of its origin, you can usually treat Windows on iphone OS and Mac OS X windows as well. That is, you typically do not have to manipulate the view-related property variables in the UIWindow object directly.

When you create an application window, you should always set its initial border size to the size of the entire screen. If your window is loaded from a nib file, Interface Builder does not allow you to create a window that is smaller than the screen size, however, if your window is created programmatically, you must pass in the desired bounding rectangle when you create it. There is no reason to pass in other bounding rectangles other than the screen rectangle. The screen rectangle can be obtained from the UIScreen object, as shown in the following code:

uiwindow* awindow = [[UIWindow alloc] Initwithframe:[[uiscreen Mainscreen] Bounds]] autorelease];

While iphone OS supports stacking a window over other windows, your application should never create multiple windows. The system itself uses additional windows to display the system status bar, important warnings, and other messages located above the application window. If you want to display a warning above your content, you can use the warning view provided by uikit instead of creating additional windows.

UIView is a function view

is an instance of the UIView class and is responsible for defining a rectangular area on the screen. In iphone applications, views play a key role in presenting the user interface and in responding to user interface interactions. Each view object is responsible for rendering the content in the view rectangle area and responding to the touch events that occur in that area. This dual behavior means that the view is an important mechanism for the application to interact with the user. In a model-view-controller-based application, the View object is clearly part of the view.

In addition to displaying content and handling events, views can also be used to manage one or more child views. A child view is a view object that is embedded inside the border of another view object, and the embedded view is called a parent view or a super view. This layout of the view is called the view hierarchy, a view can contain any number of sub-views, and the view can be nested in any depth by adding a child view to the child view. How the view is organized in the view hierarchy determines what is displayed on the screen because the child view is always displayed above its parent view, and this organizational method also determines how the view responds to events and changes. Each parent view is responsible for managing its immediate child views, adjusting their location and dimensions as needed, and responding to events that they do not handle.

Because view objects are the primary way to interact with applications and users, they need to work in a number of ways, and here are a few of them:

Depiction and animation

The view is responsible for depicting the rectangular area to which it belongs.

Some view property variables can be animated to transition to a new value.

Layout and child view Management

The view manages a list of sub-views.

A view defines the resizing behavior of itself relative to its parent view.

When necessary, the view can adjust the size and position of its child views through code.

A view can convert points under its coordinate system to points under other views or window coordinate systems.

Event handling

Views can receive touch events.

A view is a contributor to a responder chain.

In the iphone app, views and view controllers work closely together to manage view behavior in several ways. The purpose of the view controller is to handle the loading and unloading of views, to handle the interface rotation caused by device rotation, and to interact with advanced navigation objects for building complex user interfaces. For more information on this, see the "Role of the View Controller" section.

Much of this chapter looks at explaining these effects of views and how to associate your own custom code with existing UIView behavior.

View class for Uikit

The UIView class defines the basic behavior of the view, but does not define its visual representation. Instead, Uikit uses its subclasses to define the specific appearance and behavior of standard interface elements such as text boxes, keys, and toolbars. Figure 2-1 shows a hierarchical block diagram of all Uikit view classes. In addition to the UIView and Uicontrol classes, most of the views in this block diagram are designed to be used directly or in conjunction with delegate objects.

Figure 2-1 Class hierarchy of views
View class Hierarchy

This view hierarchy can be divided into the following major categories:

Container

The container view is used to enhance the functionality of other views, or to provide additional visual separation for the contents of the view. For example, the Uiscrollview class can be used to display views that are too large to be displayed on a single screen. The UITableView class is a subclass of the Uiscrollview class that manages the list of data. Table rows can support selection, so it is often also used for hierarchical data navigation-for example, to mine a set of hierarchically structured objects.

The Uitoolbar object is a special type of container that provides visual grouping for one or more key-like items. The toolbar usually appears at the bottom of the screen. Safari, Mail, and photos programs use toolbars to display keys that represent frequently used commands. Toolbars can be displayed all the time, or they can be displayed according to the needs of the application.

Control

Control is used to create the user interface for most applications. A control is a special type of view that inherits from the Uicontrol superclass, is typically used to display a specific value, and handles all user interactions that are required to modify the value. Controls typically use standard system paradigms (such as Target-action mode and delegate mode) to notify the application that user interaction has occurred. Controls include keystrokes, text boxes, sliders, and toggle switches.

Show View

Controls and many other types of views provide interactive behavior, while others are simply used to display information simply. The Uikit classes with this behavior include Uiimageview, UILabel, Uiprogressview, and Uiactivityindicatorview.

text and Web views

Text and Web views provide a more advanced way for applications to display multiple lines of text. The Uitextview class supports displaying and editing multiple lines of text within a scrolling region, while the UIWebView class provides a way to display HTML content that allows you to integrate graphics and advanced text formatting options into your application and to lay out your content in a customized way.

warning views and action forms

Warning views and action forms are used to instantly get the user's attention. They display a message to the user, along with one or more optional keys that the user responds to in response to the message. Warning views and action forms are similar in functionality, but look and behave differently. For example, The Uialertview class pops up a blue warning box on the screen, while the Uiactionsheet class slides out of the action box from the bottom of the screen.

Navigation View

The page labels and the navigation bar are used in conjunction with the view Controller to provide the user with a navigation tool from one screen to another. When used, you typically do not have to create Uitabbar and uinavigationbar items directly, but instead configure them with the appropriate controller interface or interface Builder.

window

The window provides a surface that depicts the content, and is the root container for all other views. Each application usually has only one window. For more information, see the "Role of UIWindow" section.

In addition to views, Uikit also provides a view controller for managing these objects. For more information, see the "Role of the View Controller" section.

The role of the view controller

Applications running on the iphone OS have many choices about how to organize content and how to present content to users. An application that contains a lot of content can divide content into multiple screens. At run time, behind each screen is a set of view objects that are responsible for displaying the data for that screen. The view behind a screen is a view controller that manages the data displayed on those views and coordinates their relationships with other parts of the application.

The Uiviewcontroller class is responsible for creating the views it manages and moving them out of the content when they are low in memory. The view controller also provides automatic responses for some standard system behavior. For example, if the application supports this direction when responding to changes in the device direction, the view controller can resize the view it manages to fit in the new direction. You can also use the view controller to display the new view above the current view in a modal box.

In addition to the underlying Uiviewcontroller class, Uikit contains a number of advanced subclasses that handle some of the advanced interfaces common to the platform. In particular, the navigation controller is used to display content with a hierarchy of multiple screens, whereas the page labels controller enables users to switch between a set of different screens, each representing a different mode of operation for the application.

For more information about how to manage views on the user interface through the view controller, see the View Controller Programming Guide for the iphone OS.

View Schemas and Geometry properties

Because the view is the focus object of the iphone application, it is important to understand the interaction between the views and the rest of the system. The standard view class in Uikit provides an amount of free-of-charge for the application, and provides some well-defined integration points through which you can customize the standard behavior to complete the work your application needs to do.

The following section of this article explains the standard behavior of the view and explains where you can integrate your custom code. If you need integration point information for a particular class, see the reference documentation for that class. You can get a list of all class reference documents from the Uikit framework reference.
View Interaction Model

At any time, when the user interacts with your program interface, or if your code makes some changes programmatically, a complex sequence of events will occur inside Uikit. At some specific points in the sequence of events, Uikit calls your view classes, giving them the opportunity to respond to events on behalf of the application. Understanding these call points is important to help you understand where your view objects and systems are combined. Figure 2-2 shows the basic sequence of events from the user tapping the screen to the content of the graphics System Update screen. The basic steps for triggering an event programmatically are the same, except that there is no initial user interaction.

Figure 2-2 Interaction between Uikit and your view objects
UIKit interactions with your view objects

The following steps illustrate the sequence of events in Figure 2-2, explaining what happened at each stage of the sequence, and how the application might respond.

The user strikes the screen.

The hardware reports the strike event to the Uikit framework.

The Uikit framework encapsulates the strike information as a Uievent object and sends it to the appropriate view (see the "Passing of events" section for a detailed explanation of how Uikit can deliver the event to your view).

The event handling method for a view can respond to an event in the following way:

Adjusts the property variables (borders, boundaries, transparency, and so on) of the view or its child views.

Identifies the view (or its child view) as needing to modify the layout.

Marking a view (or its child view) as a layout requires redrawing.

Notify the controller of changes in the data that occurred.

Of course, the above-mentioned things need to be done and what method to invoke to complete is determined by the view.

If the view is identified as requiring a re-layout, Uikit invokes the Layoutsubviews method of the view.

You can override this method in your own custom view to adjust the size and position of the child view. For example, if a view has a large scrolling area, you need to use several sub-views to "tile" instead of creating a large view that the memory is likely to not fit. In the implementation of this method, the view can hide any child views that do not need to be displayed on the screen, or use them to display new content after repositioning. As part of this process, the view can also identify the sub-view used for "tiling" as requiring redrawing.

If any part of the view is identified as requiring redrawing, Uikit calls the view's DrawRect: method.

Uikit calls this method only for those views that need to be redrawn. In the implementation of this method, all views should redraw the specified area as quickly as possible, and should only redraw their own content, not the contents of the child view. At this point of call, the view should not attempt to further change its properties or layout.

All updated views are composited with other visual content and then sent to the graphics hardware for display.

The graphics hardware transfers the rendered content to the screen.

Please note: The above update models are primarily intended for applications that incorporate built-in views and mapping techniques. If your application uses OpenGL ES to depict content, you typically configure a full-screen view and then paint directly in the graphics context of OpenGL. Your view still needs to handle touch events, but you don't need to lay out the sub-views or implement DrawRect: methods. For more information about OpenGL ES, see the "Painting with OpenGL ES" section.

Based on the steps described above, Uikit provides the following key binding points for your own custom views:

Here are the event handling methods:

Touchesbegan:withevent:

Touchesmoved:withevent:

Touchesended:withevent:

Touchescancelled:withevent:

Layoutsubviews method

DrawRect: Method

Most custom views implement these methods to get the behavior you expect. You may not need to overload all methods, for example, if you implement a fixed-size view, you may not need to overload the Layoutsubviews method. Similarly, if you implement a view that simply displays simple content, such as text or images, you can often avoid painting by simply embedding Uiimageview and Uilabel objects as sub-views.

It is important to remember that these are the main points of integration, but not all. There are several methods in the UIView class designed to make subclasses overloaded. You can find out which methods can be overloaded by looking at the descriptions in the UIView class reference.
View Rendering Schema

Although you represent content on the screen through a view, many of the underlying behavior of the UIView class itself is heavily dependent on another object. Behind each View object in Uikit is a core animation layer object, which is an instance of the Calayer class that provides basic support for the layout and rendering of the view content, as well as compositing and animation.

Unlike Mac OS X (which is optional for core animation support on this platform), the IPhone OS integrates core animation into the view rendering implementation. While core animation plays a central role, Uikit provides a transparent interface layer on the core animation to make the programming experience smoother. This transparent interface allows developers to achieve similar behavior in most cases without having to directly access the core animation layer, but by UIView method and property declarations. However, when the UIView class does not provide the interface you need, Core animation becomes important, in which case you can drill down into the core animation layer to implement some complex rendering in your application.

Go to---window and view schema Introduction!