Introduction to Windows and view architecture of IOS uikit framework!

Windows and views

Windows and views are for iPhone applicationsProgramConstruct visual components of the user interface. The window provides a background platform for content display, while the view is responsible for describing most of the content and responding to user interaction. Although the concepts and windows and views discussed in this chapter are related, the discussion process is more focused on views, because views are more important to the system.

View is so important to iPhone applications that it is impossible to discuss all aspects of the view in a chapter. This chapter focuses on the basic attributes of the window and view, the relationship between each attribute, and how to create and operate these attributes in the application. This chapter does not discuss how views respond to touch events or how to draw custom content. For more information about those topics, see "event processing" and "graphics and profiling.

What are windows and views?

Like Mac OS x, iPhone OS displays graphical content on the screen through windows and views. Although there are many similarities between windows and view objects on the two platforms, their functions vary slightly from platform to platform.

Functions of uiwindow

Unlike Mac OS X applications, iPhone applications usually have only one window, which indicates an instance of the uiwindow class. When your application starts, create the window (or load it from the NIB file), add one or more views to the window, and display it. After the window is displayed, you rarely need to reference it again.

In iPhone OS, window objects are not visually decorated like closed boxes or title bars. You cannot directly close them or perform other operations. All operations on the window must be implemented through its programming interface. Applications can use window objects to transfer events. The window object keeps track of the current first responder object and transmits the event when the uiapplication object initiates a request.

Another thing that may surprise experienced Mac OS X developers is the inheritance relationship of the uiwindow class. In Mac OS x, the parent class of nswindow is nsresponder, while in iPhone OS, the parent class of uiwindow is uiview. Therefore, windows are also a view object in iPhone OS. Regardless of the origin, you can usually treat windows on iPhone OS as windows on Mac OS X. That is to say, you do not need to directly operate the attribute variables related to views in the uiwindow object.

When creating 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 cannot create a window smaller than the screen size. However, if your window is created programmatically, the expected border rectangle must be input during creation. Except for the screen rectangle, there is no reason to pass in other border rectangles. The screen rectangle can be obtained through the uiscreen object.CodeAs follows:

Uiwindow * awindow = [[uiwindow alloc] initwithframe: [uiscreen mainscreen] bounds] autorelease];

Although the iPhone OS supports stacked windows above other windows, your application should never create multiple windows. The system itself uses an additional window to display system status entries, 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 the function view

Is an instance of the uiview class, which defines a rectangular area on the screen. In iPhone applications, views play a key role in displaying user interfaces and responding to user interface interactions. Each view object is responsible for rendering the content in the rectangular area of the view and responding to the touch events in the area. This double action means that the view is an important mechanism for applications to interact with users. In a Model-View-controller-based application, the view object obviously belongs to the view part.

In addition to displaying content and processing events, views can also be used to manage one or more child views. A subview is a view object embedded in the border of another view object. An embedded view is called a parent view or a superview. This layout method is called view hierarchy. A view can contain any number of subviews. By adding subviews to a subview, the view can be nested in any depth. The structure of a view in the view hierarchy determines the content displayed on the screen, because the subview is always displayed above its parent view; this organization method also determines how the view responds to events and changes. Each parent view is responsible for managing its direct child views, that is, adjusting their positions and sizes as needed and responding to events they have not processed.

View objects are the main way for applications to interact with users, so they need to play a role in many aspects. The following is a small part:

Plotting and animation

A view is used to describe the area of a rectangle.

Some view attribute variables can transition to new values in the form of animations.

Layout and sub-View Management

A view manages a subview list.

A view defines its own size adjustment behavior relative to its parent view.

If necessary, the view can adjust its size and position through code.

A view can convert a point in its coordinate system to a point in another view or window coordinate system.

Event Processing

The view can receive touch events.

A view is a participant in the responder chain.

In iPhone applications, views and view controllers work closely together to manage view behavior in several aspects. View controllers are used to handle view loading and unloading, interface rotation caused by device rotation, and interaction with advanced navigation objects used to build complex user interfaces. For more information, see "Role of View Controller.

Most of the content in this chapter focuses on explaining these functions of the view and how to associate your custom code with the existing uiview behavior.

 

View class of uikit

The uiview class defines the basic behavior of a view, but does not define its visual representation. In contrast, uikit uses its subclass to define the specific appearance and behavior of standard interface elements such as text boxes, buttons, and toolbar. Figure 2-1 shows the hierarchies of all uikit view classes. Except for the uiview and uicontrol classes, most of the views in this block diagram are designed to be used directly or in combination with the delegate object.

Figure 2-1 class hierarchy
View class hierarchy

The view hierarchy can be divided into the following categories:

Container

The container view is used to enhance the functionality of other views or provide additional visual separation for the View content. For example, the uiscrollview class can be used to display a view that cannot be displayed on a screen because the content is too large. The uitableview class is a subclass of the uiscrollview class for managing data lists. Table rows can be selected, so they are usually used for hierarchical data navigation-for example, to mine a group of hierarchical objects.

A uitoolbar object is a special type of container that provides a visual group for one or more key-like items. The toolbar usually appears at the bottom of the screen. Safari, mail, and photos programs all use toolbar to display some buttons, which represent frequently used commands. The toolbar can be displayed all the time or as needed by the application.

Widget

Controls are used to create user interfaces for most applications. A control is a special type of view that inherits from the uicontrol superclass. It is usually used to display a specific value and process all user interactions required to modify this value. The control usually uses a standard system Paradigm (such as the target-action mode and delegate mode) to notify the application of user interaction. Controls include buttons, text boxes, slide, and switch.

Display View

Controls and many other types of views provide interactive behavior, while other views are only used to simply display information. The uikit class with such behavior includes uiimageview, uilabel, uiprogressview, and uiactivityindicatorview.

Text and Web View

Text and Web View provide more advanced methods for applications to display multiple lines of text. The uitextview class allows you to display and edit multiple lines of text in a rolling area. The uiwebview class provides a method to display HTML content, you can integrate graphics and advanced text format options into your application and customize the content.

Warning view and Action Form

The warning view and action form are used to get the user's attention immediately. They display a message to the user, and there are one or more optional buttons through which the user responds to the message. The warning view and action form have similar functions, but they have different appearances and actions. For example, the uialertview class displays a blue warning box on the screen, while the uiactionsheet class slides out the action box from the bottom of the screen.

Navigation View

The tab and navigation bar are used together with the View Controller to provide users with a navigation tool from one screen to another. Generally, you do not need to create uitabbar and uinavigationbar items directly, but configure them through an appropriate Controller Interface or interface builder.

Window

The window provides a surface for plotting content, which is the root container of all other views. Each application usually has only one window. For more information, see the section "functions of uiwindow.

In addition to views, uikit also provides a View Controller for managing these objects. For more information, see "Role of View Controller.

Role of View Controller

Applications running on iPhone OS have many options for how to organize and present content to users. Applications with a lot of content can divide the content into multiple screens. At runtime, each screen is behind a group of view objects that are responsible for displaying data on the screen. Behind a screen view 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 its managed views and removing them from the content when the memory is low. View controllers also provide automatic responses to certain standard system behaviors. For example, in response to changes in the device direction, if the application supports this direction, the view controller can adjust the size of the view it manages to adapt it to the new direction. You can also use the View Controller to display the new view above the current view in a mode box.

In addition to the basic uiviewcontroller class, uikit also contains many advanced subclasses used to process some common advanced interfaces of the platform. In particular, the navigation controller is used to display multi-screen content with a certain level; while the page signature controller allows users to switch between different screens, each screen represents a different operation mode of 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 iPhone OS.

 

View architecture and Geometric Attributes

View is the focus object of iPhone applications, so it is important to understand the interaction between view and other parts of the system. The standard view class in uikit provides a considerable number of behaviors for applications free of charge and some well-defined integration points. You can use these integration points to customize standard behaviors, complete the work required by the application.

The following sections describe the standard behavior of a view and describe where your custom code can be integrated. For information about integration points of a specific class, see the reference documents of this class. You can obtain a list of all class reference documents from the uikit framework reference.
View Interaction Model

At any time, when a user interacts with your program interface, or your code is modified programmatically, a complex event sequence occurs in the uikit. At some specific points in the event sequence, uikit calls your view class so that they have the opportunity to respond to the event on behalf of the application. It is important to understand these call points and help you understand where your view objects are combined with the system. Figure 2-2 shows the sequence of basic events from the user touch screen to the graphic system update screen content. The basic steps for triggering events programmatically are the same, but there is no initial user interaction.

Figure 2-2 interaction between uikit and your view object
Uikit interactions with your view objects

The following steps further explain the Event Sequence in Figure 2-2, explain what happened in each stage of the sequence, and how the application may respond.

User touch screen.

The hardware reports the hitting event to the uikit framework.

The uikit framework encapsulates the hitting information as a uievent object and distributes it to the appropriate view (detailed explanation of how uikit delivers events to your view, see the "event transfer" section ).

View event handling methods can respond to events in the following ways:

Adjust the attribute variables (border, border, transparency, etc.) of a view or its subviews ).

Mark a view (or its subviews) as the layout to be modified.

You need to redraw a view (or its subviews) as a layout.

Report changes to the Controller.

Of course, the view determines what needs to be done and how to call it.

If the view is identified as needing to be laid out again, uikit calls the layoutsubviews method of the view.

You can reload this method in your custom view to adjust the size and position of the subview. For example, if a view has a large scrolling area, you need to use several sub-views to "tile", rather than creating a large view with memory that may not fit. In the implementation of this method, the view can hide all subviews that do not need to be displayed on the screen, or use them to display new content after positioning. As part of this process, the view can also identify the child view for "tiled" as the need to be repainted.

If any part of the view is marked as being re-painted, uikit calls the drawrect: Method of the view.

Uikit only calls this method for views that need to be re-painted. In the implementation of this method, all views should re-draw the specified area as soon as possible, and only their own content should be re-painted, instead of the sub-View content. At this call point, the view should not try to further change its properties or layout.

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

The graphic hardware transfers the rendered content to the screen.

Note: The above update model is mainly applicable to applications that adopt the built-in view and plotting technology. If your application uses OpenGL ES to describe the content, you usually need to configure a full-screen view and then draw it directly in the OpenGL graphics context. Your view still needs to handle touch events, but you do not need to layout the child view or implement drawrect: method. For more information about OpenGL ES, see "draw with OpenGL ES.

Based on the preceding steps, we can see that uikit provides the following key points for custom views:

The following event handling methods:

Touchesbegan: withevent:

Touchesmoved: withevent:

Touchesended: withevent:

Touchescancelled: withevent:

Layoutsubviews Method

Drawrect: Method

Most custom views implement these methods to get their desired behavior. You may not need to reload all methods. For example, if your view is fixed, you may not need to reload the layoutsubviews method. Similarly, if you implement a view that only displays simple content, such as text or images, You can embed the uiimageview and uilabel objects as subviews to avoid plotting.

It is important to remember that these are the main points of integration, but not all. Several Methods in the uiview class are designed to overload the subclass. You can refer to the descriptions in the uiview class reference to learn which methods can be reloaded.
View rendering Architecture

Although you use a view to represent the content on the screen, many basic behaviors of the uiview class depend heavily on another object. In uikit, each view object is backed by a core animation layer object, which is an instance of the calayer class, this class provides basic support for layout and rendering of View content, as well as merging and animation.

Unlike Mac OS x (core animation support is optional on this platform), iPhone OS integrates core animation into the core of view rendering implementation. Although core animation plays a core role, uikit provides a transparent interface layer on core animation to make the programming experience smoother. This transparent interface makes it unnecessary for developers to directly access the core animation layer in most cases, but to get similar behavior through the uiview method and attribute declaration. However, when the uiview class does not provide the interface you need, core animation becomes important. In that case, you can go deep into the core animation layer, implement some complex rendering in the application.