iOS Auto Layout Demystified, Second Edition (2014)

Chapter 1. Introducing Auto Layout

Auto Layout re-imagines the way developers create user interfaces. It provides a flexible and powerful system that describes how views and their content relate to each other and to the superviews they occupy. In contrast to older design approaches, this technology offers incredible control over layout, with a wider range of customization than you can get with frames, springs, and struts.

Auto Layout has garnered both a loyal user base and fanatical detractors. Its reputation for difficulty and frustration, particularly when used through Interface Builder (IB), are occasionally merited. Although Xcode 5 vastly improves that situation (by doing away with several baffling and alienating features), this is a technology that continues to evolve toward full maturity.

Auto Layout is a fantastic tool. It does things that earlier technologies could never dream of. From edge case handling to creation of reciprocal relationships between views, Auto Layout introduces immense power. What’s more, Auto Layout is compatible with many of Apple’s most exciting application programming interfaces (APIs), including animations, motion effects, and sprites.

That’s why this book exists. You’re about to learn Auto Layout mastery by example, with plenty of explanations and tips. Instead of struggling with class documentation, you’ll read, in simple steps, how the system works, how to tweak it to make it work better, and why Auto Layout is far more powerful than many developers realize. You’ll discover common design scenarios and discover best practices that make Auto Layout a pleasure rather than a chore to use.

Origins

Auto Layout first debuted on iOS in 2012, as part of the iOS 6 release. It also appeared about a year earlier in OS X 10.7 Lion. Intended to replace the older springs-and-struts-based Autosizing, Auto Layout is a new system that builds relationships between views, specifying how views relate to their superviews and to each other.

Auto Layout is based on the Cassowary constraint-solving toolkit. Cassowary was developed at the University of Washington by Greg J. Badros and Alan Borning to address user interface layout challenges. Here’s what the Cassowary SourceForge project page (http://sourceforge.net/p/cassowary/wiki/Home/) says about it:

Cassowary is an incremental constraint solving toolkit that efficiently solves systems of linear equalities and inequalities. Constraints may be either requirements or preferences. Re-solving the system happens rapidly, supporting UI applications.

Cassowary was developed around an important interface phenomenon: that inequality and equality relationships occur naturally in user interfaces. Cassowary developed a rule-based system that enabled developers to describe these relationships between views. These relationships were described through constraints. Constraints are rules that describe how one view’s layout is limited with respect to another. For example, a view might occupy only the left half of the screen, or two views might always need to be aligned at their bottoms.

Cassowary offers an automatic solver that transforms its system of constraint-based layout rules (essentially a set of simultaneous linear equations, if you’re a math geek) into view geometries that express those rules. Cassowary’s constraint system is powerful and nuanced. Since its debut, Cassowary has been ported to JavaScript, .NET/Java, Python, Smalltalk, C++, and, via Auto Layout, to Cocoa and Cocoa Touch.

In iOS and OS X, the constraint-powered Auto Layout efficiently arranges the views in your interface. You provide rules, whether through IB or through code, and the Auto Layout system transforms those rules into view frames.

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.

Constraints

Now that you’ve read about the why of Auto Layout, this section introduces the what. Here’s the basic vocabulary you need to start talking about this technology.

Constraints, as you learned earlier, are rules that allow you to describe view layout. They limit how things relate to each other and specify how they can be laid out. With constraints, you can say “these items are always lined up in a horizontal row” or “this item resizes itself to match the height of that item.” Constraints provide a layout language that you add to views to describe geometric relationships.

The constraints you work with belong to the NSLayoutConstraint class. This Objective-C class specifies relationships between view attributes, such as heights, widths, positions, and centers. What’s more, constraints are not limited to equalities. They can describe views using greater-than-or-equal and less-than-or-equal relations so that you can say that one view must be at least as big as or no bigger than another. Auto Layout development is built around creating and adjusting these relationship rules in a way that fully defines your interfaces.

Together, an interface’s constraints describe the ways views can be laid out to dynamically fit any screen or window geometry. In Cocoa and Cocoa Touch, a well-defined interface layout consists of constraints that are satisfiable and sufficient.