技术的乐趣在于分享,欢迎多多交流,多多沟通。
全部博文(877)
分类: iOS平台
2015-08-20 17:40:29
The UIView
class defines a rectangular area on the screen and the interfaces for managing the content in that area. At runtime, a view object handles the rendering of any content in its area and also handles any interactions with that content. The UIView
class itself provides basic behavior for filling its rectangular area with a background color. More sophisticated content can be presented by subclassing UIView
and implementing the necessary drawing and event-handling code yourself. The UIKit framework also includes a set of standard subclasses that range from simple buttons to complex tables and can be used as-is. For example, a UILabel
object draws a text string and a UIImageView
object draws an image.
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 using technologies such as UIKit, Core Graphics, and OpenGL ES.
Some view properties can be animated to new values.
Layout and subview management
A view may contain zero or more subviews.
Each view defines its own default resizing behavior in relation to its parent view.
A view can define the size and position of its subviews as needed.
Event handling
A view is a responder and can handle touch events and other events defined by the UIResponder
class.
Views can use the addGestureRecognizer:
method to install gesture recognizers to handle common gestures.
Views can embed other views and create sophisticated visual hierarchies. This creates a parent-child relationship between the view being embedded (known as the subview) and the parent view doing the embedding (known as the superview). Normally, a subview’s visible area is not clipped to the bounds of its superview, but in iOS you can use the clipsToBounds
property to alter that behavior. A parent view may contain any number of subviews but each subview has only one superview, which is responsible for positioning its subviews appropriately.
The geometry of a view is defined by its frame
, bounds
, and center
properties. The frame
defines the origin and dimensions of the view in the coordinate system of its superview and is commonly used during layout to adjust the size or position of the view. The center
property can be used to adjust the position of the view without changing its size. The bounds defines the internal dimensions of the view as it sees them and is used almost exclusively in custom drawing code. The size portion of the frame
and bounds rectangles are coupled together so that changing the size of either rectangle updates the size of both.
For detailed information about how to use the UIView
class, see View Programming Guide for iOS.
To create a view programmatically, you can use code like the following:
CGRect viewRect = CGRectMake(10, 10, 100, 100);
UIView* myView = [[UIView alloc] initWithFrame:viewRect];
This code creates the view and positions it at the point (10, 10) in its superview’s coordinate system (once it is added to that superview). To add a subview to another view, you use the addSubview:
method. In iOS, sibling views may overlap each other without any issues, allowing complex view placement. The addSubview:
method places the specified view on top of other siblings. You can specify the relative z-order of a subview by adding it using the insertSubview:aboveSubview:
and insertSubview:belowSubview:
methods. You can also exchange the position of already added subviews using theexchangeSubviewAtIndex:withSubviewAtIndex:
method.
When creating a view, it is important to assign an appropriate value to the autoresizingMask
property to ensure the view resizes correctly. View resizing primarily occurs when the orientation of your application’s interface changes but it may happen at other times as well. For example, calling the setNeedsLayout
method forces your view to update its layout.
View drawing occurs on an as-needed basis. When a view is first shown, or when all or part of it becomes visible due to layout changes, the system asks the view to draw its contents. For views that contain custom content using UIKit or Core Graphics, the system calls the view’s drawRect:
method. Your implementation of this method is responsible for drawing the view’s content into the current graphics context, which is set up by the system automatically prior to calling this method. This creates a static visual representation of your view’s content that can then be displayed on the screen.
When the actual content of your view changes, it is your responsibility to notify the system that your view needs to be redrawn. You do this by calling your view’s setNeedsDisplay
or setNeedsDisplayInRect:
method of the view. These methods let the system know that it should update the view during the next drawing cycle. Because it waits until the next drawing cycle to update the view, you can call these methods on multiple views to update them at the same time.
For detailed information about the view drawing cycle and the role your views have in this cycle, see View Programming Guide for iOS.
Changes to several view properties can be animated—that is, changing the property creates an animation that conveys the change to the user over a short period of time. The UIView
class does most of the work of performing the actual animations but you must still indicate which property changes you want to be animated. There are two different ways to initiate animations:
In iOS 4 and later, use the block-based animation methods. (Recommended)
Use the begin/commit animation methods.
The block-based animation methods (such as animateWithDuration:animations:
) greatly simplify the creation of animations. With one method call, you specify the animations to be performed and the options for the animation. However, block-based animations are available only in iOS 4 and later. If your application runs on earlier versions of iOS, you must use the beginAnimations:context:
and commitAnimations
class methods to mark the beginning and ending of your animations.
The following properties of the UIView
class are animatable:
For more information about how to configure animations, see View Programming Guide for iOS.
Manipulations to your application’s user interface must occur on the main thread. Thus, you should always call the methods of the UIView
class from code running in the main thread of your application. The only time this may not be strictly necessary is when creating the view object itself but all other manipulations should occur on the main thread.
The UIView
class is a key subclassing point for visual content that also requires user interactions. Although there are many good reasons to subclass UIView
, it is recommended that you do so only when the basicUIView
class or the standard system views do not provide the capabilities that you need. Subclassing requires more work on your part to implement the view and to tune its performance.
For information about ways to avoid subclassing, see Alternatives to Subclassing.
When subclassing UIView
, there are only a handful of methods you should override and many methods that you might override depending on your needs. Because UIView
is a highly configurable class, there are also many ways to implement sophisticated view behaviors without overriding custom methods, which are discussed in the Alternatives to Subclassing section. In the meantime, the following list includes the methods you might consider overriding in your UIView
subclasses:
Initialization:
initWithFrame:
- It is recommended that you implement this method. You can also implement custom initialization methods in addition to, or instead of, this method.
initWithCoder:
- Implement this method if you load your view from an Interface Builder nib file and your view requires custom initialization.
layerClass
- Implement this method only if you want your view to use a different Core Animation layer for its backing store. For example, if your view uses tiling to display a large scrollable area, you might want to override this method and return the CATiledLayer
class.
Drawing and printing:
drawRect:
- Implement this method if your view draws custom content. If your view does not do any custom drawing, avoid overriding this method.
drawRect:forViewPrintFormatter:
- Implement this method only if you want to draw your view’s content differently during printing.
Constraints:
requiresConstraintBasedLayout
- Implement this class method if your view class requires constraints to work properly.
updateConstraints
- Implement this method if your view needs to create custom constraints between your subviews.
alignmentRectForFrame:
, frameForAlignmentRect:
- Implement these methods to override how your views are aligned to other views.
Layout:
sizeThatFits:
- Implement this method if you want your view to have a different default size than it normally would during resizing operations. For example, you might use this method to prevent your view from shrinking to the point where subviews cannot be displayed correctly.
layoutSubviews
- Implement this method if you need more precise control over the layout of your subviews than either the constraint or autoresizing behaviors provide.
didAddSubview:
, willRemoveSubview:
- Implement these methods as needed to track the additions and removals of subviews.
willMoveToSuperview:
, didMoveToSuperview
- Implement these methods as needed to track the movement of the current view in your view hierarchy.
willMoveToWindow:
, didMoveToWindow
- Implement these methods as needed to track the movement of your view to a different window.
Event Handling:
touchesBegan:withEvent:
, touchesMoved:withEvent:
, touchesEnded:withEvent:
,touchesCancelled:withEvent:
- Implement these methods if you need to handle touch events directly. (For gesture-based input, use gesture recognizers.)
gestureRecognizerShouldBegin:
- Implement this method if your view handles touch events directly and might want to prevent attached gesture recognizers from triggering additional actions.
Many view behaviors can be configured without the need for subclassing. Before you start overriding methods, consider whether modifying the following properties or behaviors would provide the behavior you need.
addConstraint:
- Define automatic layout behavior for the view and its subviews.
autoresizingMask
- Provides automatic layout behavior when the superview’s frame changes. These behaviors can be combined with constraints.
contentMode
- Provides layout behavior for the view’s content, as opposed to the frame
of the view. This property also affects how the content is scaled to fit the view and whether it is cached or redrawn.
contentStretch
- Defines portions of the view as being stretchable. This behavior is typically used to implement buttons and other resizable views with sophisticated layout needs where redrawing the view every time would affect performance.
hidden
or alpha
- Change the transparency of the view as a whole rather than hiding or applying alpha to your view’s rendered content.
backgroundColor
- Set the view’s color rather than drawing that color yourself.
Subviews - Rather than draw your content using a drawRect:
method, embed image and label subviews with the content you want to present.
Gesture recognizers - Rather than subclass to intercept and handle touch events yourself, you can use gesture recognizers to send an action message to a target object.
Animations - Use the built-in animation support rather than trying to animate changes yourself. The animation support provided by Core Animation is fast and easy to use.
Image-based backgrounds - For views that display relatively static content, consider using aUIImageView
object with gesture recognizers instead of subclassing and drawing the image yourself. Alternatively, you can also use a generic UIView
object and assign your image as the content of the view’s CALayer
object.
Animations are another way to make visible changes to a view without requiring you to subclass and implement complex drawing code. Many properties of the UIView
class are animatable, which means changes to those properties can trigger system-generated animations. Starting animations requires as little as one line of code to indicate that any changes that follow should be animated. For more information about animation support for views, see Animations.
For more information about appearance and behavior configuration, see About Views in UIKit User Interface Catalog.
- initWithFrame:
Designated Initializer
backgroundColor
Property
hidden
Property
alpha
Property
opaque
Property
tintColor
Property
tintAdjustmentMode
Property
clipsToBounds
Property
clearsContextBeforeDrawing
Property
maskView
Property
layer
Property
userInteractionEnabled
Property
multipleTouchEnabled
Property
exclusiveTouch
Property
autoresizingMask
Property
autoresizesSubviews
Property
contentMode
Property
constraints
Property
- addLayoutGuide:
(New in iOS 9.0)
- removeLayoutGuide:
(New in iOS 9.0)
- viewForBaselineLayout
(iOS 9.0)
See Auto Layout Guide for more details on debugging constraint-based layout.
+ userInterfaceLayoutDirectionForSemanticContentAttribute:
(New in iOS 9.0)
layoutMargins
Property
preservesSuperviewLayoutMargins
Property
contentScaleFactor
Property
gestureRecognizers
Property
Use of the methods in this section is discouraged in iOS 4 and later. Use the block-based animation methods instead.
restorationIdentifier
Property