The views and Windows show the user interface of the application and are responsible for interface interaction. Uikit and other system frameworks provide a lot of views that you can use in place with little need for modification. You can also define your own view when the content you need to show differs greatly from what the standard view allows.
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 a sophisticated way to manage the layout and presentation of views. Understanding the work of these methods is important so that you can make sure that the view has the appropriate behavior when the application changes.
View Schema Fundamentals
Most of the things you want to visualize are done by the view object-that is, an instance of the UIView class. A View object defines a rectangular area on a screen that handles drawing and touch-screen events for that area. A view can also act as a parent view of other views, while determining the location and size of those child views. The UIView class does a lot of work to manage the relationships of these internal views, but you can also customize the default behavior when needed.
The view is combined with the core animation layer to handle the interpretation and animation transitions of the view content. The views in each Uikit frame are supported by a Layer object (typically an instance of a Calayer class) that manages the view-related animations that are stored and processed in the background. However, you can use layers when you need more control over the interpretation and animation behavior of the view.
To understand the relationship between views and layers, we can draw on 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 app includes a window (also a view), a generic UIView object that behaves like a container view, an image view, a toolbar to control the display, and a toolbar button (which is not itself a view but manages a view internally). (Note that this app contains an additional image view, which is used for animating). To simplify, and because this view is usually hidden, it is not included in the diagram below. Each view has a corresponding layer object, which can be accessed through the View 礶 R property. (Because the toolbar button is not a view, you cannot directly access its Layer object.) After their layer objects are the object of the core animation, and finally the hardware cache used to manage the bits on the screen.
Figure 1-1 View Architecture
Layer objects that use core animation have significant performance implications. The drawing code of a View object needs to be called as little as possible, and when it is called, its drawing results are cached by the core animation and can be reused as much as possible in the future. Reusing what has been explained eliminates the expensive drawing cycles that typically require updating views. Reuse of content is especially important in animations, and we can use existing content, which is less expensive than creating new content.
View hierarchy and child view management
In addition to providing your own content, a view can 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 super view. Creating such a relationship has important implications for the visualization and behavior of the application.
Visually, the child view hides the contents 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 child view is partially transparent, then two views are mixed before they appear on the screen. Each parent view stores its child views in an ordered array, and the order in which they are stored affects the display of each child view. If the two sibling views overlap, then the one that is added (or the one that follows the sub-view array) appears on the other.
The parent-child view relationship also affects some view behavior. Changing the size of the parent view will be linked with changing the size and position of the child view. In this case, you can redefine the dimensions of the child view with the appropriate configuration view. Other changes that affect the child view include hiding the parent view, changing the parent view's alpha value, or converting the parent view.
The arrangement of the view hierarchy also determines how the application responds to events. Touch events that occur within a specific view are usually sent directly to the view to handle. However, if the view is not processed, it passes the event to its parent view, and so on in the responder chain. A concrete view may also pass events to an intervening responder object, like a view controller. If no object handles this event, it eventually arrives at the Application object, which is usually discarded.
For more information on how to create a view hierarchy, view creating and managing a View hierarchy
View Drawing Period
The UIView class uses an on-demand drawing model to present content. When a view first appears in front of the screen, it is asked to draw its own content. In this process, a snapshot is created that is the visible part of the view content that appears on the screen. If you have never changed the contents of the view, the drawing code for this view may never be called again. This snapshot image is reused in most of the operations involving views.
If you do change the view content, you do not redraw the view content directly. Instead, use the Setneedsdisplay or Setneedsdisplayinrect: method to revoke the view while allowing the system to redraw the content later. The system waits for the current run cycle to end and then begins the drawing operation. This delay gives you a chance to abolish multiple views, add or remove views from your hierarchy, hide, resize, and reposition the view. All the changes you make will wait at the same time to react.
Note: Changing the geometry of a view does not automatically cause the system to repaint the content. The Contentmode property of the view determines if the geometry structure should be interpreted. Most content modes Extrude or relocate an existing snapshot within the bounds of the view, and it does not recreate a new snapshot. Get more information about content mode if the drawing cycle of the view is affected, view content modes
When the content of the view is drawn, the actual drawing process changes depending on the view and its configuration. System views typically implement private drawing methods to interpret their views, (those same system views often develop interfaces so that you can configure the true performance of the view.) For custom UIView subclasses, you can usually override the DrawRect: method and use this method to draw your view content. There are other ways to provide view content, like setting content directly at the bottom layer, but overriding drawrect: the most common technique
Content mode
The content mode of the view controls how the view reclaims content to respond to changes in the view geometry, and also controls whether the content needs to be recycled. When a view is first displayed, it usually interprets the content, and the result is captured as a bitmap by the underlying hierarchy tree. After that, changing the geometry of the view does not cause the bitmap to be recreated. Conversely, the value of the Contentmode property in the view determines whether the bitmap should be stretched to fit the new boundary or simply to be placed in the corner or the boundary of the view.
The content mode of the view is applied when you do the following:
Changes the width or height of the view frame or bounds rectangle.
Assigns a value to the Transform property of the view, and the new transformation includes a scaling factor.
The Contentmode value of most views is Uiviewcontentmodescaletofiill, which causes the contents of the view to be indented to fit the new frame's values. Figure 1-2 shows the results of using other available content patterns. As you can see in the diagram, not all content patterns can fill the scope of the view, and the possible patterns may distort the content.
Content mode is a good way to support the content collection of the view, but you can also use Uiviewcontentmoderedraw content mode when you want the view to redraw and resize the operation. Setting this value plots forces the system to invoke the DrawRect of the view: method to respond to changes in the geometric structure. Generally speaking, you should avoid using this pattern as much as possible, and you should not use this pattern in a standard system view.
Get more backbone with available content mode, view UIView Class Reference
Figure 1-2
Stretch View
You can specify that a part of the view is stretchable so that only the extruded portion is affected when the view's size changes. A stretched part usually gives a view of a repeating pattern to a button or other part. The stretchable area you specify allows stretching along two or one of the axes. Of course, when a view stretches along two axes, the boundary of the view must also define a repeating pattern to avoid any distortions. Figure1-3 shows how this distortion manifests itself in the view. The colors of the original pixels in each view are copied themselves so that the corresponding area of the larger view can be populated.
Figure 1-3 Stretching the background of a button
You can use the Contentstretch property to define a stretched area of a view. The value of this property is normalized to a rectangle between 0.0 and 1.0. When this view is stretched, the system multiplies the current boundary value and the scaling factor of the view by the standard values to determine which pixels need to be stretched. Using standard values can alleviate the need to update the Contentstretch property every time the boundary value of the view is changed.
The content mode of the view also plays an important role in determining how the stretched area of the view is used. An extruded area is used only when the content pattern may be drawn to cause the view content to be indented. This means that your stretched view is only Uiviewcontentmodescaletofill, Uiviewcontentmodescaleaspectfit and Uiviewcontentmodescaleaspectfill content mode. If you specify a content pattern that bounces content to a border or a corner (so there is no real retraction), this view ignores the stretchable area.
Note: Using the Contentstretch property is recommended when you need to create an extruded UIImage object as the background of the view. The stretched view is handled entirely by the core animation layer, which typically performs better.
Embedded animation support
One of the benefits of using layer objects to support views is that you can easily animate view-related changes with animations. Animation is a useful way to communicate information with users, and it should always be considered in the process of applying design. Many of the properties of the UIView class are animated-that is, the change from one value animation to another can be semi-automatic. In order to achieve such an animation, all you need to do is:
1 tell Uikit you want to implement an animation
2 Changing the value of this property
There are the following animated properties in a UIView object:
Frame-You can use this to animate the size and position of the view
Bounds-Use this to animate the size of the view
Center-Use this to animate the position of the view
Transform-Use this to flip or zoom in on a view
Alpha-Use this to change the transparency of the view
BackgroundColor-Use this to change the background color of the view
Contentstretch-Use this to change how the view content is stretched
An important part of animation is the transition from one set of views to another. Typically, a view controller is used to manage animations that relate to the main changes in the user interface. For example, interfaces that involve navigating from high-level to underlying information typically use a navigation controller to manage the transitions of views that show each successive layer of data. However, you can also use animations to create transitions for two sets of views, rather than a view controller. You might do this when you want to use a system-provided navigation scheme that is not supported by the view controller.
In addition to creating animations with the Uikit class, you can also create animations with the core animation layer. At the lower level you have more control over the time or animation properties.
For more information on how to create a view-based animation, see animations
For more information on creating animations using core Animation, see Core Animation Programming Guide and Core Animation Cookbook.
View geometry and coordinate systems
The default coordinate system of the Uikit sets the origin in the upper-left corner, two axes down and right. Marking is represented as a floating-point number, allowing the content to be precisely laid out and positioned regardless of the underlying screen. Figure1-4 shows the coordinate system relative to the screen. In addition to the screen coordinate system windows and views also define their own local coordinate system, which allows you to specify coordinates relative to the view or window origin instead of the screen.
Figure 1-4 the coordinate system in Uikit
Because each view and window defines its own local coordinate system, you need to be aware of which coordinate system is in effect at any given time. Each time a view is drawn or changed, it is based on a coordinate system. In some drawings, the coordinate system is based on the view itself. In some geometric changes, the coordinate system is based on the parent view. The UIWindow and UIView classes contain methods that help you transform from one coordinate system to another.
Important: Some iOS technologies define the default coordinate system, and their origin and orientation are different from the Uikit. For example, the coordinate system for the Core graphics and OpenGL ES is the origin point in the lower-left corner of the viewable area, and the y-axis is incremented upward. When drawing or creating content, your code should take into account some differences and adapt to the coordinate values.
The relationship between frame, bounds, and center properties
The View object uses the frame, bounds, and center properties to track its size and position:
The Frame property contains a frame rectangle that specifies the size and position of the view in the parent view coordinate system.
The Center property contains a known central point in the parent view coordinate system.
The Bounds property contains a bounding rectangle that specifies the dimensions of the view in the view's local coordinate system.
Use the center and frame properties primarily to control the geometry of the current view. For example, you can use these properties when building your view hierarchy at run time or changing the size or location of the view. If you just want to change the location of the view, it is recommended to use the Center property. The value of the center property is always available, even if the drop or transform factor is added to the transformation matrix of the view. However, for the frame property, it is not valid when the conversion rectangle of the view is not equal to the original matrix.
The Bounds property is used primarily during the drawing process. This boundary matrix is interpreted in the local coordinate system of the view. The default origin of this rectangle is (0, 0), and its size also adapts to the size of the frame rectangle. Anything drawn in this rectangle is part of the visual content of that view. If you change the origin of the bounds rectangle, anything you draw in the new rectangle becomes part of the view's visual content.
Figure1-5 shows the relationship between the frame and the bounds rectangle of an image view. In the diagram, the upper-right corner of the image view is positioned in the parent view coordinate system (40, 40), and its rectangle size is 240x380. For bounds rectangles, the origin is (0, 0), and the rectangle size is also 240x380.
Figure 1-5 View the relationship between frame and bounds
Even if you can change the Frame,bounds and center properties independently, one of the changes will affect the other two properties:
When you set the Frame property, the dimension value of the Bounds property also changes to accommodate the new size of the frame rectangle. The Center property also changes to the central value of the new frame rectangle.
When you set the center property, the frame's origin also changes accordingly.
When you set the Bounds property, the frame property changes to fit the new size of the bounds rectangle.
The frame of the view is not clipped by its parent view frame by default. In this way, any child views placed outside the parent view will be fully interpreted. You can change this behavior by changing the Clipstobounds property of the parent view. Touch-screen events always occur in the bounds rectangle of the target view's parent view, regardless of whether the child view is visually clipped. In other words, if you touch a portion of the view that is outside the parent view, the event is not sent to that view.
Coordinate system transformation matrix
The coordinate system transformation matrix provides an easy and easy way to change the view (or its view). An affine transformation is a mathematical matrix that specifies how points in the coordinate system are mapped to points in another coordinate system. You can apply an affine transformation to the entire view to change the size, position, or orientation of the view based on its parent view. You can also apply affine transformations in your drawing code to achieve the same manipulation of the individual parts of the interpreted content. How the affine transformations are applied is based on the context:
In order to modify the entire view, you can modify the affine transformation value of the view Transform property.
To modify the specified part of the content in the DrawRect: method in the view, you can modify the affine transformation that is related to the current drawing context.
When you want to implement an animation, you can usually modify the Transform property value of the view. For example, you can use this property to create an animation that flips the view around the center point. You should not use this property in the coordinate space of its parent view to permanently change your view, like changing its position and size. For this type of change, you can modify the view's frame rectangle.
Note: When you modify the Transform property value of a view, all conversions are based on the center point of the view.
In the DrawRect: method of the view, you can use an affine transform to locate or flip the item you want to draw. Instead of correcting the position of the object in some parts of the view, we prefer to create the object relative to a fixed point, usually (0, 0), and use the transform to position the object before drawing. In this case, if the position of the object in the view changes, all you have to do is modify the transformation matrix, which is more expensive than recreating the new location for the object. You can use the CGCONTEXTGETCTM method to get an affine transformation of the graphics context, and you can set or modify the transformation matrix using the relevant method of the core graphics in the drawing.
The current transformation matrix (CTM) is an affine matrix that is used at all times. When manipulating the geometry of the entire view, CTM is the value of the view Transform property. In the DrawRect: method, CTM is an affine matrix about the graphics context.
The coordinate system of each sub-view is built on top of the coordinate system of its ancestors. So when you modify the Transform property of a view, this change affects the view and all of its child views. However, these changes will only affect the final interpretation of the view on the screen. Because each view is responsible for drawing its own content and laying out its own child views, it can ignore the transformation of the parent view during drawing and layout.
Figure1-6 describes how two different conversion factors are visually combined at the time of interpretation. In the view's DrawRect: method, applying a 45-degree conversion factor to a shape causes the shape to flip the specified angle. Adding a 45-degree conversion factor will cause the entire shape to flip 90 degrees. This shape still flips 45 degrees for the view it was drawn on, but the view's own conversion makes it look like it flipped 90 degrees.
Figure 1-6 Flips a view and its contents
Important: If the Transform property of a view is not the transformation matrix when it is defined, then the Frame property of the view is undefined and must be ignored. When you apply transformations to a view, you must use the bounds and center properties of the views to get the location and dimensions of the view. The frame rectangles of the child view are still valid because they are related to the bounds of the view.
For more information about modifying the view's Transform property at run time, see "Translating, Scaling, and rotating views." Get more information on how to use transformations to locate content during the drawing process, view Drawing and Printing Guide for IOS.
Dots and pixels
In iOS, all coordinate values and distances are specified to use floating-point numbers whose cell values are called points. The number of points varies with the device and is not related to each other. The main point to understand about points is that they provide a fixed framework for drawing.
Table 1-1 Lists the resolution (point metric) for different iOS devices. Before the width is long. As long as you design the user interface according to the size of these screens, your view will be displayed correctly by the appropriate device.
Table 1-1
Device screen dimensions (in points)
IPhone and IPod Touch x 480
IPad 768 x 1024
Each device that uses a point-based measurement system defines a user coordinate space. This is the standard coordinate space that almost all of your code will use. For example, when you want to manipulate the geometry of a view or call the core graphics method to draw content, it uses a point and user coordinate space. Even if the coordinates in the user's coordinate space are sometimes mapped directly to the pixels on the device screen, you should never assume that this is always the same. Instead, you should remember that a point does not necessarily correspond to a pixel on the screen
At the device level, all coordinates on the view you specify must be converted to pixels at certain points. However, pixels from a point in the user's coordinate space to the device's coordinate space are usually handled by the system. Both the Uikit and core graphics use a vector-based drawing model, and all coordinate values are specified as points of use. This way, if you draw a curve with the core graphics, you will use some values to specify the curve, regardless of the solution used by the underlying screen.
When you need to work with images or other pixel-based technologies like OpenGL ES, iOS will help you manage those pixels. For a static image file that is stored as a resource in an application's bundle, iOS defines conventions that specify images of different pixel densities, or that can be used to maximize the current screen's solution when loading images. The view also provides information about the current scaling factor so that you can adjust any pixel-based drawing code appropriately to accommodate screens with more advanced solutions. Techniques for processing pixel-based content in different screen solutions can be found in "supporting high-resolution Screens" and "Drawing and Printing Guide for IOS".
Run-time interaction model for views
When the user interacts with the interface, or something is changed by the code's program, a complex set of events takes place inside the uikit to handle these interactions. At some point in this series, Uikit calls out your view class and gives them a chance to respond to the program's behavior. Understanding these call points is important for understanding where a view is integrated into the system. Figure 1-7 shows the basic sequence of these events, from the beginning of the user touch screen to the graphical System Update screen content to respond to the end. The same sequence of events also occurs in any program-initiated action.
Figure 1-7 UIKit interacting with a View object
The following steps decompose the sequence of events in Figure 1-7, explaining what happened at each step and explaining how the application responds
1 User Touch screen
2 Hardware report Touch event to Uikit frame
The 3 Uikit framework packages touch events into uievent objects and distributes them to the appropriate view. (For a detailed explanation of how the Uikit framework submits events to the view, see Event handing guide for IOS)
The event-handling code in 4 views may respond with the following actions:
Change the properties of a view or its child view (frame, bounds, alpha, and so on)
Call the Setneedslayout method to mark the view (or its child view) as requiring layout updates
Call Setneedsdisplay or Setneedsdisplayinrect: method to mark the view (or its sub-view) to be redrawn
Notifies a controller about updates to some data
Of course, what to do and which methods to invoke are determined by the view.
5 If the geometry of a view changes, uikit updates its child views according to the following rules:
A if the rules for automatically resetting dimensions are in effect, Uikit adjusts the view according to these rules. For more information on how automatic resizing rules work, see "Handling Layout changes automatically Using autoresizing rules."
b If the view implements the Layoutsubviews method, Uikit calls it. You can override this method in your custom view and use it to adjust the position and size of any child views. For example, a view that provides a huge scrolling area will need to use several sub-views as "tile" instead of creating a huge view that is unlikely to be put into memory. In the implementation of this method, the view hides any offscreen sub-views, or repositions them and then uses them to draw new visual content. As part of this process, the layout code of the view can also be used to repeal any views that need to be redrawn.
6 If any part of any view is marked for redrawing, Uikit requires the view to redraw itself.
For a custom view that explicitly defines the DrawRect: method, Uikit calls this method. The implementation of this method should redraw the specified area of the view as soon as possible and should not do anything else. Do not make additional layouts at this point, and do not change the application's data model. This method is provided only to update the visual content of the view.
Standard system views typically do not implement DrawRect: methods, but also manage their drawing at this time.
7 Any updated view is combined with the rest of the app's visual content and is sent to the graphics hardware to display.
8 graphics hardware translates the interpreted content onto the screen.
Note: The above update model is primarily applied to applications that use standard system views and drawing techniques. Apps drawn using OpenGL ES typically configure a single full-screen view and directly draw related OpenGL image contexts. Your view should still handle touch-screen events, but it is full-screen, without the need to give the child view layout or implement DrawRect: method. For more information on using OpenGL ES, see OpenGL ES Programming Guide for IOS.
Given a series of previous steps, the methods for incorporating your own custom views include:
Event Handling methods:
Touchesbegan:withevent:
Touchesmoved:withevent:
Touchesended:withevent:
Touchescancelled:withevent:
Layoutsubviews method
DrawRect: Method
These are the most common overlay methods for views, but you may not need to overwrite them all. If you use gesture recognition to handle events, you do not need to overwrite the event handling method. Similarly, if your view does not contain a sub-view or its dimensions do not change, there is no reason to overwrite the Layoutsubviews method. Finally, you only need to use DrawRect when the view content changes at run time and you want to draw with local techniques such as uikit or core graphics.
Keep in mind that these are the main points of integration, but that's not the only thing. Some of the methods in the UIView class are specifically designed to cover subclasses. You should look at the descriptions of these methods in the UIView Class reference so that you know which methods are right for you when customizing.
Tips for working with views effectively
Customizing views is useful when you need to draw something that is not available in standard system views. But you have to be responsible for ensuring that the performance of the view is high enough. Uikit will optimize the view-related behavior as much as possible, and it will also help you improve performance. However, consider some hints that can help to Uikit.
Important: Before you adjust the drawing code, you should always collect data about the current performance of your view. Estimating current performance lets you determine if there is a problem, and if there is a problem, it also provides a baseline that allows you to compare in future optimizations.
The view does not always have a corresponding view controller
In an app, a one-to-one relationship between views and view controllers is rare. The work of a view controller is to manage a hierarchy of views, and the view hierarchy often contains multiple views, all of which have self-contained attributes. For iphone apps, each view hierarchy is usually filled with the entire screen, although not for ipad apps.
When you design the user interface, it is important to consider the role that the view controller plays. The view controller provides a number of important behaviors, such as reconciling views, reconciling view culling, freeing memory to respond to low memory warnings, and flipping views in response to changes in the orientation of the interface. Escaping these behaviors can result in an application error.
For more information about view controllers, see View Controller Programming Guide for IOS
Minimized custom Painting
Although custom painting is sometimes needed, you should try to avoid it. The real need for custom painting is when the existing view class does not provide enough performance and ability. Any time your content should be assembled into other views, the best result is to combine those view objects into a custom view hierarchy
Leverage content Mode
Content mode minimizes the time it takes to repaint a view. By default, the view uses the Uiviewcontentmodescaletofill content mode, which indents the existing contents of the view to populate the view's frame rectangle. You can change this mode to adjust your content when needed, but you should avoid using Uiviewcontentmoderedraw content mode. Regardless of which content pattern is in effect, you can call Setneedsdisplay or Setneedsdisplayinrect: method to force the view to redraw its contents.
Declare the view opaque if possible
Uikit uses the Opaque property to determine whether it can optimize the operation. Setting this property of a custom view to Yes tells Uikit that there is no need to interpret any content that is behind the view. This can improve performance and is recommended for your drawing code. Of course, if you set this property to Yes, your view must completely fill its bounds rectangle with opaque content.
Adjust the drawing behavior of a view when scrolling
Scrolling causes several views to be updated in a short period of time. If the drawing code of the view is not properly adjusted, the performance of the scrolling will be very slow. Rather than always guaranteeing the mediocrity of the view content, we tend to consider changing the view behavior at the beginning of the scrolling operation. For example, you can temporarily reduce the content that has been explained, or change the content mode when scrolling. When scrolling stops, you can return the view to the previous state and update the content as needed.
Do not embed child views to customize controls
Despite the technical addition of sub-views to standard system control objects-inheriting from Uicontrol classes-it is possible that you should never use this method to customize them. Control objects support customization, and they have an explicit and well-documented interface. For example, the UIButton class contains methods for setting the title and background picture. Using a defined custom point means that your code will always work correctly. Without these methods, embedding a custom image view or a label into a button will result in unexpected results for the application.
The above content is Official document translation (originates from the network), if you English also can, please see English address: English address
UIView's Anatomy is a good summary.http://blog.csdn.net/mengtnt/article/details/6716289
UIView, how much do you know?
Start building with 50+ products and up to 12 months usage for Elastic Compute Service
1 on 1 presale consultation
24/7 Technical Support 6 Free Tickets per Quarter Faster Response
Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.
A comprehensive suite of global cloud computing services to power your business
Payment Methods We Support
