This chapter is from the book
This chapter is from the book
This chapter is from the book
Saying “Yes” to Auto Layout
There are many reasons developers want to say “No” to Auto Layout. Maybe it’s too new, too strange, or requires a bit of work to update interfaces. But you should say “Yes.” Auto Layout revolutionizes view layout with something wonderful, fresh, and new. Apple’s layout features make your life easier and your interfaces more consistent, and they add resolution-independent placement for free. You get all this, regardless of device geometry, orientation, and window size.
Auto Layout works by creating relationships between onscreen objects. It specifies the way the runtime system automatically arranges your views. The outcome is a set of robust rules that adapt to screen and window geometry. With Auto Layout, you describe constraints that specify how views relate to one another, and you set view properties that describe a view’s relationship to its content. With Auto Layout, you can make requests such as the following:
- Match one view’s size to another view’s size so that they always remain the same width.
- Center a view (or even a group of views) in a superview, no matter how much the superview reshapes.
- Align the bottoms of several views while laying out a row of items.
- Offset a pair of items by some constant distance (for example, adding a standard 8-point padding space between views).
- Tie the bottom of one view to another view’s top so that when you move one, you move them both.
- Prevent an image view from shrinking to the point where the image cannot be fully seen at its natural size. (That is, don’t compress or clip the view’s content.)
- Keep a button from showing too much padding around its text.
The first five items in this list describe constraints that define view geometry and layout, establishing visual relationships between views. The last two items relate a view to the content it presents. When working with Auto Layout, you negotiate both these kinds of tasks.
Here are some of the strengths that Auto Layout brings to your development.
Geometric Relationships
Auto Layout excels at building relationships. Figure 1-1 shows a custom iOS control built entirely with Auto Layout. This picker enables users to select a color. Each pencil consists of a fixed-size tip view placed directly above a stretchable bottom view. As users make selections, items move up and down together to indicate their current choice. Auto Layout constraints ensure that each tip stays exactly on top of its base, that each “pencil” is sized to match its fellows, and that the paired tip and base items are laid out in a bottom-aligned row.
)
Figure 1-1 This pencil-picker custom control was built entirely with Auto Layout.
This particular pencil picker is built programmatically; that is, a data source supplies the number of pencils and the art for each tip. By describing the relationships between the items, Auto Layout simplifies the process of extending this control. You need only say “place each new item to the right, match its width to the existing pencils, and align its bottom” to grow this picker from 10 items to 11, 12, or more. Best of all, constraint changes can be animated. The pencil tip animates up and down as the base reshapes to new constraint offsets.
The following code shows how these items were laid out in my project:
// This sample extensively uses custom macros to minimize the
// repetition and wordiness of this code, while giving a sense of the
// design choices and layout vocabulary offered by Auto Layout.
// Read more about similar custom macros in Chapter 6.
- (void) layoutPicker
{
for (int i = 0; i < segmentCount; i++)
{
// Add base
UIImageView *base = [[UIImageView alloc] initWithImage:baseArt];
base.tag = i + 1;
[self addSubview:base];
PREPCONSTRAINTS(base);
// Load tip
UIImageView *tip = [[UIImageView alloc] initWithImage:segmentArt[@(i)]];
tip.tag = i + 1001;
[self addSubview:tip];
PREPCONSTRAINTS(tip);
// Constrain tips on top of base
CONSTRAIN_VIEWS(@"V:[tip][base]|", tip, base);
// Left align tip and base
ALIGN_LEFT(tip, base);
// Tips and base have same width so
// match the tip width to the base width
MATCH_WIDTH(tip, base);
}
// Set up leftmost base
UIView *view1 = [self viewWithTag:1];
ALIGN_LEFT(view1, 0);
// Line up the bases
for (int i = 2; i <= segmentCount; i++)
{
// Each base to the right of the previous one
UIView *view1 = [self viewWithTag:i-1];
UIView *view2 = [self viewWithTag:i];
CONSTRAIN_VIEWS(@"H:[view1][view2]", view1, view2);
}
for (int i = 1; i <= segmentCount; i++)
{
// Create base height constraint so the
// base's height (the pencil without the tip) is
// fixed to the value of baseHeight
UIImageView *base = (UIImageView *)[self viewWithTag:i];
baseHeight = base.image.size.height;
CONSTRAIN_HEIGHT(base, baseHeight);
// Create tip size constraints fixing the
// tip's width and height to these values
UIImageView *tip = (UIImageView *)[self viewWithTag:i + 1000];
CONSTRAIN_WIDTH(tip, targetWidth);
CONSTRAIN_HEIGHT(tip, targetHeight);
}
}
Content-Driven Layout
Auto Layout is content driven. That is, it considers a view’s content during layout. For example, imagine a resizable content view with several subviews, like the one shown in Figure 1-2. Suppose that you want to be able to resize this view but don’t want to clip any subview content while doing so. Auto Layout helps you express these desires and rank them so that the system makes sure not to clip when resizing.
)
Figure 1-2 Auto Layout can ensure that the stretchable button shown in the original view (left) won’t clip while resizing. The window cannot resize any smaller than the small view (right) because doing so would cause either the label or button to clip.
Figure 1-2 shows a small OS X application whose primary window protects the content of its two subviews. (Throughout this book, I try to add a few OS X examples where possible. Auto Layout is virtually identical on iOS and OS X.) These subviews include a label whose content is the string Label and a resizable button whose content is, similarly, the string Button. The left side of the figure shows the original content view as the application launches; the right side shows the same window after it’s been resized to its minimum extent.
At the right of Figure 1-2, you see the smallest possible version of this view. Because its Auto Layout rules resist clipping (these rules are called compression resistance), the window cannot resize any further. The only way to allow it to shrink beyond this size is to demote or remove one or both of its “do not clip” subview rules. A similar rule, called content hugging, allows a view to resist padding and stretching, keeping the frame of each view close to the natural size of the content it presents.
Keep content in mind and adapt your rules as your views change the data they present. For example, if you were switching from one language to another, you might need the width of each label and button to adapt to different word lengths. For example, localizing English text to Spanish or Portuguese might cause a 20%–25% expansion in word size. Localizing to Hebrew or Arabic can shrink English text by a third.
Prioritized Rules
With prioritized rules, Auto Layout weighs the importance of layout choices and adapts to challenging edge conditions and special cases. Rule balancing is an important part of Auto Layout design work. You not only specify the layout qualities of each view but also prioritize them. When rules come into conflict—and they do quite regularly—the system uses your rankings to select the most important layout qualities to preserve.
In the example of Figure 1-2, the integrity of the label and of the button contents have priority over any request for a smaller window. This forces a natural minimum on the window size and prevents the window from resizing any further than that.
Inspection and Modularization
One of the great things about Auto Layout is how well it can be centralized and inspected. This is, however, a benefit only if you create your layouts in code. While you can browse constraints in IB, and even visualize them with the proper tools, recovering the intent of each layout choice is an intractable issue.
In code, you can compartmentalize your rules to common methods (such as loadView and updateViewConstraints) and freely annotate them. Code trades off review against visualization. You can inspect your layouts with ease to ensure that your logic is properly expressed. You cannot preview those rules, however, except by running the application.
You can easily modularize constraints. Once you’ve built a routine that centers a view in its superview, you can re-use that routine indefinitely. By building a library of common constraint requests (for example, “align this view to the bottom” or “create a row of these views with center-Y alignment”), you cause your layout code to refine over time in both real-world readability and overall reliability. You can see this modularization in the code example that accompanies Figure 1-1.
Incremental Adoption
Auto Layout is backward compatible. Interfaces and nib files built using older Autosizing technology still work in Auto Layout. You are welcome to mix and match autoresizing views with constraint-based layout. For example, you can load a nib whose subviews are laid out using struts and springs and allow that view, in turn, to operate as a first-class member of the Auto Layout world. The key is encapsulation.
As long as rules do not directly conflict (for example, you can’t say “stretch using Autosizing” and “stretch using Auto Layout” at the same time on a single view), you can reuse complex views you have already established in your projects. You can, for example, load Autosizing nibs and seamlessly place them into your Auto Layout scenes.