The Core iOS Developer’s Cookbook, Fifth Edition (2014)

---

Connections

Place connections between view names to specify the way a layout flows. An empty connection (in other words, one that has been omitted) means “follow on directly.”

The first constraint you saw for Figure 5-2, "H:[view1][view2]", uses an empty connection. There’s nothing specified between the square brackets of View 1 and the brackets of View 2. This tells the constraint to place View 2 directly to the right of View 1.

A hyphen (-) indicates a small fixed space. The constraint "H:[view1]-[view2]" uses a hyphen connection. This constraint leaves a standard (as defined by Apple) gap between View 1 and View 2, as shown in Figure 5-3.

Figure 5-3 "H:[view1]-[view2]" adds a spacer connection.

Place a numeric constant between hyphens to set an exact gap size. The constraint "H:[view1]-30-[view2]" adds a 30-point gap between the two views, as shown in Figure 5-4. This is visibly wider than the small default gap produced by the single hyphen.

Figure 5-4 "H:[view1]-30-[view2]" uses a fixed-size gap of 30 points, producing a noticeably wider space.

The format "H:|[view1]-[view2]|" specifies a horizontal layout that starts with the superview. The superview is immediately followed by the first view, then a spacer, the second view, and then the superview, which you can see in Figure 5-5.

This constraint left-aligns View 1 and right-aligns View 2 with the superview. To accomplish this, something has to give. Either the left view or the right view must resize to meet these constraints. When we ran the test app for this edition, it happened to be View 1 that adjusted, which is what you see in Figure 5-5. In the previous edition, it happened to be View 2.

Figure 5-5 "H:|[view1]-[view2]|" tells both views to hug the edges of their superview. With a fixed-size gap between them, at least one of the views must resize to satisfy the constraint.

Often, you don’t want to bang up right against the superview edges. A similar constraint, "H:|-[view1]-[view2]-|", leaves an edge inset between the edges of the superview and the start of View 1 and end of View 2 (see Figure 5-6).

Figure 5-6 "H:|-[view1]-[view2]-|" introduces edge insets between the views and their superviews.

These gaps follow standard IB/Cocoa Touch layout rules and have not yet been exposed in specifics via the iOS API. The inset gaps at the edges are normally slightly larger than the default view-to-view gaps. You can see the gap size differences in the view layout created from this constraint in Figure 5-6.

If your goal is to add a flexible space between views, there’s a way to do that, too. Add a relation rule between the two views (for example, "H:|-[view1]-(>=0)-[view2]-|") to allow the two views to retain their sizes and be separate while maintaining gaps at their edges with the superview, as shown in Figure 5-7. This rule, which equates to “at least 0 points distance,” provides a more flexible way to let the views spread out. It is recommended to use a small number here so that you don’t inadvertently interfere with a view’s other geometry rules.

Figure 5-7 "H:|-[view1]-(>=0)-[view2]-|" uses a flexible space between the two views, allowing them to separate, while maintaining their sizes.

These constraints are not, of course, limited to just one or two views. You can easily stick in a third, fourth, or more. Consider this constraint: "H:|-[view1]-[view2]-(>=5)-[view3]-|". It adds a third view, separated from the other two views by a flexible space. Figure 5-8 shows what this might look like.

Figure 5-8 "H:|-[view1]-[view2]-(>=5)-[view3]-|" demonstrates a rule that includes three views.

Predicates

The last two examples in the previous section uses relationship rules with comparisons. These are also called predicates, an affirmation of the way a relation works between view elements. Predicates appear in parentheses. For example, you might specify that the size of a view is at least 50 points by using the following format:

[view1(>=50)]

This predicate relates to a single view. Notice that it is included within the view’s square brackets rather than as part of a connection between views. You’re not limited to a single request. For example, you might use a similar approach to let a view’s size range between 50 and 70 points. When adding compound predicates, separate the parts of your rule with commas:

[view1(>=50, <=70)]

Relative relation predicates allow your views to grow. If you want your view to expand across a superview, tell it to size itself to some value greater than zero. The following rule stretches a view horizontally across its superview, allowing only for edge insets at each side:

H:|-[view1(>=0)]-|

Figure 5-9 shows what this constraint looks like when rendered.

Figure 5-9 "H:|-[view1(>=0)]-|" adds a flexibility predicate to the view, letting it stretch across its parent. Edge insets offset it slightly from the superview’s sides.

When using an equality relationship (==), you can skip the double-equals in your format predicates. For example [view1(==120)] is equivalent to [view1(120)], and [view1]-(==50)-[view2] is the same as [view1]-50-[view2].

Metrics

When you don’t know a constant’s value (like 120 or 50) a priori, use a metrics dictionary to provide the value. This dictionary is passed as one of the parameters to the constraint creation method. Here is an example of a format string that uses a metric stand-in:

[view1(>=minwidth)]

The minwidth stand-in must map to an NSNumber value in the passed metric dictionary. For more examples of metric use, refer to Recipe 5-2’s constrainSize: method. It demonstrates how to use metrics, using values from an associated dictionary in its constraints.

View-to-View Predicates

Predicates aren’t limited to numeric constants. You can relate a view’s size to another view, for example, to ensure that it’s no bigger than that view in the layout. This example limits View 2’s extent to no bigger than that of View 1, along the axis that the constraint is currently using:

[view2(<=view1)]

You can’t do a lot more with format strings and view-to-view comparisons. If you want to establish more complex relationships, like those between centers, tops, and heights, skip the visual format strings and use the item constraint constructor instead.

Priorities

Each constraint may specify an optional priority by adding an at sign (@) and a number or metric. For example, you can say that you want a view to be 500 points wide but that the request has a relatively low priority:

[view1(500@10)]

You place priorities after predicates. Here’s an example of a layout format string with an embedded priority:

[view1]-(>=50@30)-[view2]

Format String Summary

Table 5-2 summarizes format string components used to create constraints with the constraintsWithVisualFormat:options:metrics:views: class method of NSLayoutConstraint.

Table 5-2 Visual Format Strings

Aligning Views and Flexible Sizing

It is supremely easy to align views with constraints:

The four format strings "H:|[self]", "H:[self]|", "V:|[self]", and "V:[self]|", respectively, produce left, right, top, and bottom alignment.

Add a predicate with a sizing relation, and these format strings become stretch to left, stretch to right, and so on: "H:|[self(>0)]", "H:[self(>0)]|", "V:|[self(>0)]", and "V:[self(>0)]|".

A second vertical pipe adds full-axis resizing, allowing views to stretch from left to right or top to bottom: "H:|[self(>0)]|" or "V:|[self(>0)]|".

Add edge indicators to inset the stretches: "H:|-[self(>0)]-|" or "V:|-[self(>0)]-|".

Constraint Processing

The display of a view’s content proceeds through multiple phases. Prior to Auto Layout, two phases were provided: the layout phase and the rendering phase. Auto Layout augments the traditional two phases by inserting a third phase to kick off the process—the constraint phase.

The layout phase allows a developer to modify the frame geometry of the view’s subviews by implementing the layoutSubviews method. When iOS determines the view’s layout to be invalid, this method will be called, and you can update the manual layout of your subviews. You can also request a relayout by calling setNeedsLayout or layoutIfNeeded. The first method is a polite request that allows iOS to coalesce multiple layout requests and call layoutSubviews at an appropriate time in the future. The second method is more demanding, resulting in a nearly immediate call to layoutSubviews.

The rendering phase allows for complete control over the drawing of the view’s UI by implementing the drawRect: method. When the view’s display is invalidated, the method will be called, allowing for low-level drawing into the view. If the rendering needs to be changed, you can request the view to be redrawn with setNeedsDisplay or setNeedsDisplayInRect:, triggering a call to drawRect:.

With Auto Layout, the constraints phase occurs prior to the preceding phases. This phase allows for the creation or updating of Auto Layout constraints through implementation of the updateConstraints method. Much like the layout phase, the constraints phase can be invalidated by iOS or manually, using the similarly named and behaving setNeedsUpdate-Constraints and updateConstraintsIfNeeded methods.

Importantly, any view that overrides updateConstraints should also call [super updateConstraints] as the final step before returning from the method. After the constraints phase completes, Auto Layout has appropriately calculated the frame geometry of all the subviews in the view.

When any of the above phases resolves, the next phase is triggered. The constraints phase triggers the layout phase, which triggers the rendering phase.

The progression of phases provides a somewhat unexpected opportunity. The layout phase occurs after the constraint phase has calculated and set all the frame geometry based on the assigned constraints. Once in the layout phase, you can make changes to a view’s frame geometry that may contradict the directions set forth by your constraints. You can even use the constraint-generated geometry to make decisions on the final layout of a view. Since the constraints have already been calculated, changing the frame geometry will “stick” until the next constraints phase. Be careful that your layout pass does not make constraint changes and trigger an infinite loop of layout and update constraint calls.

Most of the time, these hooks are not needed. On rare occasions when they’re required, the level of flexibility and control provided is empowering.

Managing Constraints

All constraints belong to the NSLayoutConstraint class, regardless of how they are created. When working with constraints, you can add them to your views either one by one, using addConstraint:, or in arrays by using the addConstraints: instance method (notice the s at the end of the name). In day-to-day work, you often deal with collections of constraints that are stored in arrays.

A constraint always has a natural home in the nearest common ancestor of the views involved in the constraint. A constraint must be installed on a common ancestor of every view referenced. A self-installing category method on NSLayoutConstraint can programmatically determine the natural and correct view for installation. This is left as an exercise for the reader.

Constraints can be added and removed at any time. The two methods, removeConstraint: and removeConstraints:, enable you to remove one or an array of constraints from a given view. Because these methods work on objects, they might not do what you expect them to do when you attempt to remove constraints.

Suppose, for instance, that you build a center-matching constraint and add it to your view. You cannot then build a second version of the constraint with the same rules and expect to remove the first by using a standard removeConstraint: call. They are equivalent constraints, but they are not the same constraint. Here’s an example of this conundrum:

[self.view addConstraint:
[NSLayoutConstraint constraintWithItem:textField
attribute:NSLayoutAttributeCenterX
relatedBy:NSLayoutRelationEqual
toItem:self.view
attribute:NSLayoutAttributeCenterX
multiplier:1.0f constant:0.0f]];
[self.view removeConstraint:
[NSLayoutConstraint constraintWithItem:textField
attribute:NSLayoutAttributeCenterX
relatedBy:NSLayoutRelationEqual
toItem:self.view
attribute:NSLayoutAttributeCenterX
multiplier:1.0f constant:0.0f]];

Executing these two method calls ends up as follows: The self.view instance contains the original constraint, and the attempt to remove the second constraint is ignored. Removing a constraint not held by the view has no effect.

You have two choices for resolving this. First, you can hold onto the constraint when it’s first added by storing it in a local variable. Here’s what that would look like, more or less:

NSLayoutConstraint *myConstraint =
[NSLayoutConstraint constraintWithItem:textField
attribute:NSLayoutAttributeCenterX
relatedBy:NSLayoutRelationEqual
toItem:self.view
attribute:NSLayoutAttributeCenterX
multiplier:1.0f constant:0.0f];
[self.view addConstraint:myConstraint];

// later
[self.view removeConstraint:myConstraint];

Or you can use a method (see Recipe 5-1) that compares constraints and removes a constraint that numerically matches the one you pass.

Knowing whether your constraints will be static (used for the lifetime of your view) or dynamic (updated as needed) helps you decide which approach you need. If you think you might need to remove a constraint in the future, either hold on to it via a local variable so that you can later remove it from your view or use workarounds like the one detailed in Recipe 5-1.

Here are some basic points you need to know about managing constraints:

You can add constraints to and remove constraints from view instances. The core methods are addConstraint: (addConstraints:), removeConstraint: (removeConstraints:), and constraints. The last of these returns an array of constraints stored by the view.

Constraints are not limited to container views. Nearly any view can work with constraints. (A class method, requiresConstraintBasedLayout, specifies whether classes depend on constraints to operate properly.)

If you want to code a subview with constraints, switch off the subview’s translatesAutoresizingMaskIntoConstraints property. You’ll see this in action in the sample code for this chapter and further discussed in the “Debugging Your Constraints” section toward the end of this chapter.

Recipe: Comparing Constraints

All constraints use a fixed structure in the following form, along with an associated priority:

view1.attribute (relation) view2.attribute * multiplier + constant

Each element of this equation is exposed through a constraint’s object properties—namely priority, firstItem, firstAttribute, relation, secondItem, secondAttribute, multiplier, and constant. These properties make it easy to compare two constraints.

Views store and remove constraints as objects. If two constraints are stored in separate memory locations, they’re considered unequal, even if they describe the same conditions. To allow your code to add and remove constraints on-the-fly without storing those items locally, use comparisons.

Recipe 5-1 introduces three methods. The constraint:matches: method compares the properties in two constraints to determine whether they match. Note that only the equation is considered, not the priority (although you can easily add this if you want), because two constraints describing the same conditions are essentially equivalent, regardless of the priority a developer has assigned to them.

The two other methods, constraintMatchingConstraint: and removeMatching-Constraint:, respectively, help locate the first matching constraint stored within a view and remove that matching constraint.

In Recipe 5-1, a view is bounced from the top and bottom of its superview by removing a matched constraint and replacing it with a new constraint. In this case, it might be easier to store this constraint as an instance variable for simple removal at a future point. That said, the ability to retrieve and remove a similar constraint can be very useful when working with many constraints or removing specific constraints dynamically.