UIView class defines a rectangular area on the screen and the interfaces for managing the content in that area.
- iOS 2.0+
- tvOS 2.0+
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
UIImage 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 Declared property 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.
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
clips 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
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
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.
Creating a View
To create a view programmatically, you can use code like the following:
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
add method. In iOS, sibling views may overlap each other without any issues, allowing complex view placement. The
add 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
insert methods. You can also exchange the position of already added subviews using the
When creating a view, it is important to assign an appropriate value to the
autoresizing 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
set method forces your view to update its layout.
The View Drawing Cycle
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
draw(_:) 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
set 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
animate(with) 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
commit 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.
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 basic
UIView 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.
Methods to Override
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
init(frame:)- It is recommended that you implement this method. You can also implement custom initialization methods in addition to, or instead of, this method.
init(coder:)- Implement this method if you load your view from an Interface Builder nib file and your view requires custom initialization.
layerUse this property 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 set the property to the
Drawing and printing:
requiresUse this property if your view class requires constraints to work properly.
Constraint Based Layout
update- Implement this method if your view needs to create custom constraints between your subviews.
size- 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.
layout- Implement this method if you need more precise control over the layout of your subviews than either the constraint or autoresizing behaviors provide.
touches- Implement these methods if you need to handle touch events directly. (For gesture-based input, use gesture recognizers.)
gesture- Implement this method if your view handles touch events directly and might want to prevent attached gesture recognizers from triggering additional actions.
Recognizer Should Begin(_:)
Alternatives to Subclassing
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.
add- Define automatic layout behavior for the view and its subviews.
autoresizing- Provides automatic layout behavior when the superview’s frame changes. These behaviors can be combined with constraints.
content- Provides layout behavior for the view’s content, as opposed to the
frameof the view. This property also affects how the content is scaled to fit the view and whether it is cached or redrawn.
background- Set the view’s color rather than drawing that color yourself.
Subviews - Rather than draw your content using a
draw(_:)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 Target-Action 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 a
UIImageobject with gesture recognizers instead of subclassing and drawing the image yourself. Alternatively, you can also use a generic
UIViewobject and assign your image as the content of the view’s
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.