In Chapter 4, you learned that a view’s frame specifies its size and position relative to its superview. So far, you have defined the frames of your views with absolute coordinates either programmatically or by configuring them in Interface Builder. Absolute coordinates, however, make your layout fragile because they assume that you know the size of the screen ahead of time.
Using Auto Layout, you can describe the layout of your views in a relative way that allows the frames to be determined at runtime so that the frames’ definitions can take into account the screen size of the device that the application is running on.
The screen size for each device is listed in Table 15.1. (Remember that points are used when laying out your interface and map to physical pixels on the device’s screen. A retina device has the same size screen in points as a non-retina device, even though it has twice as many pixels.)
Table 15.1 Device Screen Sizes
| Device | Width x Height (points) |
|---|---|
| iPhone/iPod (4S and earlier) | 320 x 480 |
| iPhone/iPod (5 and later) | 320 x 568 |
| All iPads | 768 x 1024 |
The Auto Layout system works with yet another rectangle for a view – the alignment rectangle. This rectangle is defined by several layout attributes (Figure 15.5).
- Width/Height
-
These values determine the alignment rectangle’s size.
- Top/Bottom/Left/Right
-
These values determine the spacing between the given edge of the alignment rectangle and the alignment rectangle of another view in the hierarchy.
- CenterX/CenterY
-
These values determine the center point of the alignment rectangle.
- Baseline
-
This value is the same as the bottom attribute for most, but not all, views. For example, UITextField defines its baseline to be the bottom of the text it displays rather than the bottom of the alignment rectangle. This keeps “descenders” (letters like ‘g’ and ‘p’ that descend below the baseline) from being obscured by a view right below the text field.
|
Leading/Trailing |
These values are used with text-based views like UITextField and UILabel. If the language of the device is set to a language that reads left-to-right (e.g., English), then the leading attribute is the same as the left attribute and the trailing attribute is the same as the right attribute. If the language reads right-to-left (e.g., Arabic), then the leading attribute is on the right and the trailing attribute is on the left. |
By default, every view in a XIB file has an alignment rectangle, and every view hierarchy uses Auto Layout. But, as you have seen in your detail view, the default will not always work as you want. This is when you need to step in.
You do not define a view’s alignment rectangle directly. You do not have enough information (screen size!) to do that. Instead, you provide a set of constraints. Taken together, these constraints allow the system to determine the layout attributes, and thus the alignment rectangle, for each view in the view hierarchy.
A constraint defines a specific relationship in a view hierarchy that can be used to determine a layout attribute for one or more views. For example, you might add a constraint like “the vertical space between these two views should always be 8 points” or “these views must always have the same width.” A constraint can also be used to give a view a fixed size, like “this view’s height should always be 44 points.”
You do not need to have a constraint for every layout attribute. Some values may come directly from a constraint; others will be computed by the values of related layout attributes. For example, if a view’s constraints set its left edge and its width, then the right edge is already determined (left edge + width = right edge, always).
If, after all of the constraints have been considered, there is still an ambiguous or missing value for a layout attribute, then there will be errors and warnings from Auto Layout and your interface will not look as you expect on all devices. Debugging these problems is important, and you will get some practice later in this chapter.
How do you come up with constraints? Let’s see how using the view in the BNRDetailViewController’s view hierarchy that will be simple to constrain – the toolbar.
First, describe what you want the view to look like regardless of screen size. For the toolbar, you could describe it like this:
-
The toolbar should sit at the bottom of the screen.
-
The toolbar should be as wide as the screen.
-
The toolbar’s height should be 44 points. (This is Apple’s standard for instances of UIToolbar.)
To turn this description into constraints in Interface Builder, it will help to understand how to find a view’s nearest neighbor. The nearest neighbor is the closest sibling view in the specified direction (Figure 15.6).
If a view does not have any siblings in the specified direction, then the nearest neighbor is its superview, also known as its container.
Now you can spell out the constraints for the toolbar:
-
The toolbar’s bottom edge should be 0 points away from its nearest neighbor (which is its container – the view of the BNRDetailViewController).
-
The toolbar’s left edge should be 0 points away from its nearest neighbor.
-
The toolbar’s right edge should be 0 points away from its nearest neighbor.
-
The toolbar’s height should be 44 points.
If you consider the second and third constraints, you can see that there is no need to explicitly constrain the toolbar’s width. It will be determined from the constraints on the toolbar’s left and right edges. There is also no need to constrain the toolbar’s top edge. The constraints on the bottom edge and the height will determine the value of the top attribute.
Now that you have a plan for the toolbar, you can add these constraints. Constraints can be added using Interface Builder or in code.
Apple recommends that you add constraints using Interface Builder whenever possible. This is what you will do in this chapter. However, if your views are created and configured programmatically, then you can add constraints in code. In Chapter 16, you will get a chance to practice that approach.