iOS Auto Layout Demystified, Second Edition (2014)

---

Content Size Constraints

Every view’s frame consists of an origin (the location at which the view sits) and a size (the width and height of that view within its parent). Although you can express exact rules for both position and size, sometimes you want Auto Layout to infer sizing from a view’s content. You work with two kinds of constraints related to content size: content hugging and compression resistance. These rules specify how easily Auto Layout can stretch, squash, or pad a view in relation to that intrinsic size.

Intrinsic Content Size

As you read in Chapter 1, “Introducing Auto Layout,” the sizes of labels, image views, and controls often depend on the content they present. For example, a button labeled Go! can be narrower than a Share Link or Send Feedback button. An image is sized both by its underlying art and a natural screen scale. Whenever a view’s bounds vary in this way, content size enables Auto Layout to automatically fit that material into its rules.

Views without natural content report an intrinsic content size of (–1, –1). UIKit declares this “no content” size as UIViewNoIntrinsicMetric. AppKit on OS X offers no equivalent. Apple writes:

Note that not all views have an intrinsicContentSize. UIView’s default implementation is to return (UIViewNoIntrinsicMetric, UIViewNoIntrinsicMetric). The _intrinsic_content size is concerned only with data that is in the view itself, not in other views. Remember that you can also set constant width or height constraints on any view, and you don’t need to override instrinsicContentSize if these dimensions won’t be changing with changing view content.

Content Hugging

Content hugging constraints restrict the amount of stretching and padding a view allows itself to experience. A high-content hugging priority matches a view’s frame to its intrinsic content size. If that content size is small, you will want the frame to be small as well. The lines of force pull inward to the view’s natural edges to resist padding (see Figure 2-1).

Figure 2-1 Content hugging squeezes a view inward, toward its content, to match that content’s natural size and avoid padding or stretching.

Consider Figure 2-2. It shows an image view displaying an application icon. Layout constraints tell this view to center itself and to stretch out to fill as much screen as possible.

Figure 2-2 Views with low content hugging priorities may stretch to large sizes.

The top part of Figure 2-2 shows this view using a very high (required) content hugging priority. The view’s bounds constrict to the base size, producing a small centered result. The middle and bottom parts of the figure use a low content hugging priority. As a result, the view fills up a much larger portion of the screen.

Content modes account for the other difference between the middle and bottom screenshots. In iOS, content mode defines how content reshapes with respect to the view frame.

The view in the middle image in Figure 2-2 uses UIViewContentModeScaleAspectFill. The art zooms to fill up the view. The bottom image uses UIViewContentModeCenter, so its art is centered and unscaled. The colored background behind the image shows the view’s full extent, which is the same size as in the middle image.

Compression Resistance

Compression resistance constraints prevent a view from clipping its content. A high resistance priority ensures that a view’s intrinsic content is fully displayed. With compression resistance, the lines of force originate from within the content, pushing outward to ensure that the entire intrinsic content is seen (see Figure 2-3).

Figure 2-3 Compression resistance keeps views from clipping their content by matching their size to their intrinsic content.

This is demonstrated in Figure 2-4, where the widths in both images have been constrained to half their natural size (256 points instead of 512 points), using a medium (500) priority.

Figure 2-4 When a view’s compression resistance priority is lowered, the view may end up clipping its content. These views use a center content mode.

The left image uses a required (1,000) resistance priority; the right one uses a very low (1) priority. In the first case, the resistance wins out over the width constraint. In the second case, it loses to it. The view resizes below its natural content extent, and the image clips accordingly.

To create these images, I used a center content mode so that the image would display at its natural size, and I enabled clipsToBounds to ensure that the view’s image would not extend beyond its bounds.

Setting Content Size Constraints in Code

For each view, you can assign content hugging and compression resistance priorities in code. The default hugging priority is 250, and the default resistance priority is 750. Table 2-2 shows the UIKit and AppKit APIs. As you see, these differ slightly by platform. The main difference is nomenclature. UIKit refers to axes, and AppKit talks about orientations. They are, otherwise, functionally equivalent. Both axes and orientations are enumerated values. Each enumeration defines horizontal as 0 and vertical as 1.

Table 2-2 Content Size APIs for UIKit and AppKit

The priorities you assign to these methods are also equivalent. You assign a value from 1 (lowest priority) to 1,000 (required priority). In turn, these values produce the behaviors shown in Figures 2-1 through 2-4.

Setting Content Size Constraints in IB

The interactive setting pane shown in Figure 2-5 appears for some (but not all) views in Xcode 5. In IB, select a view and open the Size Inspector (by selecting View > Utilities > Show Size Inspector). If the priority sliders appear, adjust values in the View > Content Hugging Priority or View > Content Compression Resistance Priority. The sliders and stepper text fields limit those values between 1 and 1,000.

Figure 2-5 IB provides pop-up tips that describe what each priority means.

As Figure 2-5 shows, IB offers interactive tips as you adjust priorities. These tips describe the level you’re setting. For the most part, I find it easiest to skip the explanation and enter a value in the text field to the right, especially since the manual control over values while dragging is coarse.

Building Layout Constraints

Layout constraints (instances of NSLayoutConstraint) define rules about a view’s physical geometry. They specify how a view should be laid out and how a view relates to other views in the same hierarchy.

To express these rules, you use the simple mathematical vocabulary shown in Table 2-3. This vocabulary consists of view attributes, relations, and the basic operations of addition and multiplication.

Table 2-3 Elements of Constraints

The Layout Constraint Class

You create mathematical rules by building instances of the NSLayoutConstraint class and adding them to your views. Instances offer the following base properties:

priority—This attribute stores a constraint’s priority value. Priorities allow the Auto Layout system to rank constraints to choose which requests to honor. You read about priorities and their values earlier in this chapter.

firstItem and secondItem—These properties point to views. A constraint may talk about the properties of one view or the relation between two views. A valid constraint always has a non-nil first item. The second item may or may not be nil.

firstAttribute and secondAttribute—Attributes are the “nouns” of the constraint system, describing features of a view’s alignment rectangle, such as left, right, center, and height. These properties are set to any of the 12 enumerated attributes in Table 2-3. If you don’t have a second item, you set the second attribute to NSLayoutAttributeNotAnAttribute.

relation—Relations are the “verbs” of the constraint system, specifying how attributes compare to each other: the same (==), greater than or equal to (>=), or less than or equal to (<=). A constraint’s relation constant must be set to one of the three enumerated values listed in Table 2-3.

multiplier and constant—These properties provide the algebra that gives the constraint system its power and flexibility. They allow you to say one view is half the size of another or that a view is offset from its superview by a set distance. These properties are both floating-point values. They correspond to the m (multiplier) and b (constant) elements used to form the constraint equation. You can ignore any multiplier of 1 or constant of 0; they are identity operations.

Constraint Math

All constraints, regardless of how they are created, are essentially equations or inequalities with the following form:

y (relation) m * x + b

If you have a math background, you may have seen a form more like this, with R referring to the relation between y and the computed value on the right side:

y R m * x + b

y and x are view attributes of the kind listed in Table 2-3, such as width or centerY or top. Here, m is a constant scaling factor, and b is a constant offset. For example, you might say, “View B’s left side should be placed 15 points to the right of View A’s right side.” The relation equation that results is something like this:

View B’s left = View A’s right + 15

Here, the relation is equality, the constant offset (b) is 15, and the scaling factor or multiplier (m) is 1. I’ve taken care here to keep the preceding equation from looking like code because, as you’ll see, you do not use code to declare your constraints in Objective-C.

Constraints do not have to use strict equalities. They can use inequality relations as well. For example, you might say, “View B’s left side should be placed at least 15 points to the right of View A’s right side,” or

View B’s left >= View A’s right + 15

Offsets let you place fixed gaps between items, and the multipliers let you scale. Scaling proves especially useful when you’re laying out grid patterns, letting you multiply by the height of a view, not just add a fixed distance to the next view.

First and Second Items

Every relation equation you build looks like this, with the multiplier (m) and constant (b) always applying to the second item:

firstItem.firstAttribute (R) secondItem.secondAttribute * m + b

There are no hard-and-fast rules about which view must be the first item and which must be second. You assign them however you like. For example, you can do this:

View B’s left = View A’s right + 10

Or you can do this:

View A’s right = View B’s left – 10

These are essentially identical statements.

In the first example, View B is firstItem; in the second, it’s secondItem. They both describe a layout where View B appears 10 points to the right of View A. Here’s another, more visual, way of showing the relationship described by both of these two identical constraints:

[viewA]-10-[viewB]

This visual format is discussed in detail in Chapter 4, “Visual Formats.” There’s a trick to keeping math positive, as in the first example (the one with + 10 rather than – 10.) To accomplish this, you make the leading, left, or top item the firstItem, and the trailing, right, or bottom item thesecondItem. This is somewhat counterintuitive, as many people think of the request as “viewA.trailing followed by 10 points followed by viewB.leading.” But, since you can’t legally say this using NSLayoutConstraint:

View A’s trailing + 10 = View B’s leading

you have to settle either for keeping the views in order (and using a negative value that describes how much to move to get back from the secondItem to the firstItem) or flipping the view order you’re trying to produce and keeping the number positive.

As you’ll discover in Chapter 4, working with visual format strings does allow you to build this rule using a more intuitive “[viewA]-10-[viewB]”-style layout.

Creating Layout Constraints

You build layout constraints in any of three ways:

You can use IB to design your interfaces. IB can generate constraints that support your layout. You can further customize the set of constraints from within the visual editor.

You can use a visual formatting language to describe your constraints and allow the NSLayoutConstraint class to generate individual instances from your request (constraintsWithVisualFormat:options:metrics:views:).

You can build instances of the NSLayoutConstraint class by supplying each component of a base relation (constraintWithItem:attribute: relatedBy:toItem:attribute:multiplier:constant:).

Officially, the order of these three approaches matches the way Apple expects you to build your constraints, from most preferred to least preferred. The overall “safety” of the technology and guarantees of valid layout decrease as you go down the list.

Unofficially, my experiences go the opposite direction. I find that building constraints from the ground up offers the greatest level of developer control and the best expression of the Principle of Least Astonishment. If you want your interfaces to match your expectations and design, you’re generally best off building your constraints manually in code, using either of the latter two methods.

Unfortunately, while vastly improved in Xcode 5, IB may fail at several levels. It scatters constraint references around the interface. It offers no way to group and document functionally related constraints. It provides no editor that enables you to express edge conditions, which is a primary concern in working with Auto Layout design. (You explore these conditions in Chapter 6, “Building with Auto Layout.”)

At the same time, there are things that IB does really well. It provides a design tool that works in the same visual space as the result you’re creating. That’s important when you’re working on teams with nonprogrammers. It enables you to lay out items and test applications without having to write your own constraints. (It generates some of them for you.) It helps you test constraints and suggests fixes for problems in your layouts. For simple layouts, it provides fast and workable solutions.

I find that coupling IB-based storyboards and nib files with code-based constraint management provides a smooth solution for these issues. Another solution that has worked well for me involves building self-contained interface sections using Autosizing and then importing them into apps as modular Auto Layout components.

I’m not saying you can’t set up expressive constraints in IB. You can. However, inspecting the constraints you build is hard to do, and it’s impossible to do it rigorously. Plus your layout vocabulary is limited.

All three design approaches eventually end up as NSLayoutConstraint instances. No matter how you specify your Auto Layout rules, they all factor down to a set of layout constraints that are added to views in your interface.

Building NSLayoutConstraint Instances

The NSLayoutConstraint’s class method constraintWithItem:attribute: relatedBy: toItem:attribute:multiplier:constant: (gesundheit!) creates a single constraint at a time. Each layout constraint defines a rule about either one or two views.

With two views, the creation method produces a strict view.attribute R view.attribute * multiplier + constant relation, where R is one of equal-to (==), greater-than-or-equal-to (>=), or less-than-or-equal-to (<=) relations.

Consider the following example:

[self.view addConstraint:
[NSLayoutConstraint
constraintWithItem:self.view
attribute:NSLayoutAttributeCenterX
relatedBy:NSLayoutRelationEqual
toItem:textfield
attribute:NSLayoutAttributeCenterX
multiplier:1
constant:0]];

This call adds a new constraint to a view controller’s view (self.view) that horizontally center-aligns a text field. It does this by setting an equality relation (NSLayoutRelationEqual) between the two views’ horizontal centers (NSLayoutAttributeCenterX attributes). The multiplier here is 1, and the offset constant is 0. This represents the following equation:

[self.view]’s centerX = ([textfield]’s centerX * 1) + 0

It basically says, “Please ensure that my view’s center and the text field’s center are co-aligned at their X positions.”

The addConstraint: method adds that constraint to the view, where it is stored with any other constraints in the view’s constraints property.

Unary Constraints

Not all constraints reference two views. Some constraints, particularly those dealing with view sizing, operate on only a single view. For example, a constraint stating that a view’s width is 50 points doesn’t reference any other item.

These kinds of constraints are unary and do not involve a second item. In this case, the secondItem property will be nil, which you can easily test by examining the constraint:

if (constraint.secondItem == nil)
NSLog(@"Constraint is unary");

For example, you might establish a unary constraint that sets a view’s minimum width to 100 points:

NSLayoutConstraint *constraint = [NSLayoutConstraint
constraintWithItem:view
attribute:NSLayoutAttributeWidth
relatedBy:NSLayoutRelationGreaterThanOrEqual
toItem:nil
attribute:NSLayoutAttributeNotAnAttribute
multiplier:1
constant:100];
[view addConstraint:constraint];

This constraint corresponds to the following rule:

[view]’s width >= 100

The second item in this constraint is nil, and the attribute is set to “not an attribute.” You can actually set the second attribute to any attribute you like if you don’t particularly care about readability. The constraint will still work as described here because there’s no second item to refer to.

Zero-Item Constraints Are Illegal

Each constraint references either one or, more commonly, two views. You cannot create a valid constraint with no items. Consider the following code, which attempts to add a constraint with no items:

[self.view addConstraint:
[NSLayoutConstraint
constraintWithItem:nil
attribute:NSLayoutAttributeNotAnAttribute
relatedBy:NSLayoutRelationEqual
toItem:nil
attribute:NSLayoutAttributeNotAnAttribute
multiplier:1 constant:0]]

It compiles properly, without warnings. When run, however, it raises an exception:

2013-01-17 12:14:37.653 HelloWorld[17700:c07] *** Terminating app
due to uncaught exception 'NSInvalidArgumentException', reason:
'*** +[NSLayoutConstraint constraintWithItem:attribute:relatedBy:
toItem:attribute:multiplier:constant:]:
Constraint must contain a first layout item'

View Items

A constraint points to the views it affects by using the firstItem and secondItem properties. These properties are read-only and can be set only during constraint creation.

These two properties are typed as id, a fact that, frankly, irritates me. There is no circumstance I have encountered where the first and second items legally point to any other class other than views. (I suspect this is done to allow the same class to be used in both iOS and OS X.)

To address this issue, I created a trivial class category (see Listing 2-1) that provides the typed firstView and secondView properties I prefer to deal with. As with all other class categories, you want to add namespace prefixes in your own code that ensure that category methods and properties will not conflict with any future development done on Apple’s end. You have been warned.

To allow this category to work across platforms, I established a VIEW_CLASS constant that refers to the proper base class on the software development kit (SDK) I’m working with. Here’s how that’s defined across all my constraint work:

#pragma mark - Cross Platform
#if TARGET_OS_IPHONE
#define VIEW_CLASS UIView
#elif TARGET_OS_MAC
#define VIEW_CLASS NSView
#endif

This definition is used throughout the book wherever code may be applicable to both iOS and OS X. Alternatively, you can define it with this:

#if TARGET_OS_IPHONE
@compatibility_alias VIEW_CLASS UIView;
#elif TARGET_OS_MAC
@compatibility_alias VIEW_CLASS NSView;
#endif