UIView development process for iPhone applications

IPhoneDeveloping applicationsUIViewWhat do you know? Someone once said that what you see on the iphone isUIView, SoUIViewInIphoneIt plays an important role in development. SoUIViewHow much do we know. Please refer to the following questions,

If you all know this, you can bypass the content of this article. If you are not quite clear about it, I want to read the following content and you will understand it.

1. What are the meanings of bounds and frame?

2. What does UIViewContentModeScaleToFill represent in ContentMode?

3. How is the zooming area in the specified UIView in contentStretch calculated?

4. Which attribute changes in UIVIew can be animated?

5. What is the difference between the coordinate system of UIKit and the coordinate system of Core Graphics?
 
ViewAnd the window displays the application user interface, and is responsible for interface interaction. UIKit and other system frameworks provide a lotViewYou can use it locally without modifying it. When you need to display content and standardsViewYou can also define your ownView.

Whether you are using a system view or creating your own view, you need to understand the basic structure provided by the UIView and UIWindow classes. These classes provide complex methods to manage the layout and display of views. It is very important to understand the work of these methods, so that you can confirm that the view has the appropriate behavior when the application changes.

View architecture fundamentals

Most of the visualization operations you want are performed by the view object, that is, the instance of the UIView class. A view object defines a rectangular area on the screen, and simultaneously handles rendering and touch screen events in the area. A view can also be used as the parent view of other views, and determines the position and size of these child views. The UIView class has done a lot of work to manage the relationships between these internal views, but you can also customize the default behavior when needed.

The view and Core Animation layer work together to process the interpretation of the View content and the Animation transition. Each view in the UIKit framework is supported by a layer object, which is usually a CALayer class instance). It manages the view storage in the background and processes view-related animations. However, when you need more control over view interpretation and animation behavior, you can use layers.

To understand the relationship between views and layers, we can use some examples. Figure 1-1 shows the view hierarchy of the ViewTransitions sample program and its relationship to the underlying Core Animation layer. The view in the application includes a window (also a view), a general representation is like a container view's UIView object, an image view, and a toolbar for controlling the display, and a toolbar button (it is not a view but manages a view internally ). Note that this application contains an additional Image view, which is used for animation ).

To simplify the process, this view is usually hidden, so it is not included in the following figure. Each view has a corresponding layer object, which can be accessed through the view's r attribute. Because the toolbar button is not a view, you cannot directly access its layer object .) After their layer objects, they are the Core Animation interpretation objects, and finally the hardware cache used to manage the bits on the screen.

Figure 1-1 View architecture

Layer objects using Core Animation have important performance significance. The drawing code of a view object should be called as little as possible. When called, the drawing result will be cached by Core Animation and can be reused as much as possible in the future. Reusing the content that has already been explained eliminates the overhead and expensive draw cycle that usually requires updating the view. Content reuse is particularly important in animation. We can use existing content, which is less overhead than creating new content.

View hierarchy and subview Management

In addition to providing its own content, a view can also behave like a container. When a view contains other views, a parent-child relationship is created between the two views. In this relationship, the Child view is treated as a child view, and the parent view is treated as a superview. Creating such a relationship is of great significance to the visualization and behavior of the application.

Visually, the Child view hides the content of the parent view. If the child view is completely opaque, the area occupied by the Child view completely hides the corresponding area of the parent view. If the sub-view is partially transparent, the two views are mixed before they are displayed on the screen. Each parent view stores its sub-views in an ordered array. The storage order affects the Display Effect of each sub-view. If the two brothers and child views overlap, the added or placed behind the child view array will appear on the other.

Parent-Child view relationships also affect some view behaviors. Changing the size of the parent view changes the size and position of the Child view. In this case, you can use the appropriate configuration view to redefine the size of the subview. Other changes that affect the child view include hiding the parent view, changing the alpha value of the parent view, or converting the parent view.

The arrangement of view layers also determines how the application responds to events. A touch event occurs in a specific view and is usually directly sent to the view for processing. However, if the view is not processed, it will pass the event to its parent view, and so on in the responder chain. A specific view may also pass events to an intervention responder object, such as a view controller. If no object handles this event, it will eventually reach the application object, which is usually discarded.

Obtain