Learning iOS Development: A Hands-on Guide to the Fundamentals of iOS Programming (2014)

Chapter 4. Auto Layout

Apps on the iPhone and iPod touch can display their content in either portrait or landscape. And the devices come with either 3.5-inch or 4-inch displays. This makes four different layouts: portrait and landscape in each of two screen sizes. The interface you built in Chapter 3, “Introducing Storyboards,” is specifically for 4-inch portrait displays.

Even with a visual editor, creating an app to support four different layouts can be a challenge, especially when you have dynamic screen elements and, as you will see in Chapter 5, “Localization,” even different lengths for labels when the language changes. The result can be lots of customization code, as well as multiple view controllers for the same screen on your storyboard.

Auto layout is a constraint-based engine that lets you describe the relationships between views. Auto layout takes those descriptions, or constraints, and figures out how to position and size your app views for the current screen size and orientation. With it, you can create just one view controller per screen and tame the code.

This chapter shows you how to incorporate auto layout into your app design and development process. You start by discovering the key concepts of auto layout and using them to design constraints for your add/view scene. Next, you go through the process of modifying add/view to work in portrait for both screen sizes. You do this using practical design, layout, and debugging techniques. Finally, you create your own constraints and use the power of dynamically updating a controller’s constraints to add landscape support.

By the time you are done with the chapter, you will have the tools you need to design and add auto layout to any scene; you will be able to create apps that adapt to different device sizes and orientations.

Auto Layout Basics

When there is just one screen size in one orientation, designing a scene means determining what view elements are needed, then placing those elements in the view, or perhaps, in a hierarchy of views. Adding rotation increases the complexity, though it is still manageable. But as soon as you add different screen sizes in addition to interface orientations, things get more complex. Earlier versions of iOS gave you some flexibility in specifying how views adjusted when their container changed size, but usually layouts with view dependencies or mildly complex hierarchies took code. Often that code required complex calculations and updating of many views.

For example, consider running an app on different-height portrait displays. You need to know the difference in height, which views can move and/or resize, and how far they can move and/or resize. Then you need to choose which views actually move and/or resize. If the difference in height requires moving more than one view, you probably need to write code.

Rotating between portrait and landscape is even more complex. To understand this, think about the portrait interface of your favorite iPhone app that supports rotation. Now imagine how the individual view elements move as the device is rotated to landscape and back again. Look at this on a device as the rotation happens and note how much movement happens. You can see that there is a lot of work going on in a continuously changing environment. Each view goes through multiple steps. And even though the interim steps are done for you, imagine calculating the end position and size of each view. There could be so much recalculation that it would be easier to create a different layout.

Figure 4-1 shows differences in the view car area for the CarValet app in the two portrait screen sizes. The highlighted rectangles show where the two screens differ. In this case, the difference in screens is entirely contained in one text view. This works because the smaller screen size has more than enough room to show all the car details. As you create more complex apps, you rarely find just one view that can absorb the difference. You usually have to start by identifying the areas with the greatest flexibility in size, then the next greatest, and so on until you have enough of a size difference to effectively display on each screen size.

Figure 4-1 Changes in the view car area for different screen heights

Assuming that the layout is created for a 4-inch screen, you need to detect a 3.5-inch screen, calculate the difference in size, move the buttons, and resize the Car Info label. Some pseudo-code for implementing the changes follows:

if (!is4InchDisplay && (deltaHeight > 0.0)) {
carInfoLabel.frame.size.height = deltaHeight / 2.0;
previousButton.frame.origin.y -= deltaHeight;
editButton.frame.origin.y -= deltaHeight;
nextButton.frame.origin.y -= deltaHeight;
}

This is not valid Objective-C; real code would be longer. Even the pseudo-code does a lot of work for this simple case, and it is not immediately clear what the code is doing. Worse, any modification to the visual layout requires code modification.

It would be easier for you to describe how the views, or in this case groups of views, are related. The description uses three groups: Add car contains the total cars label and new car button; the separator view is by itself; and the view car group contains the rest of the elements:

The add car group height is fixed, and it is the iOS standard distance from the top of its container.

The separator view is a fixed distance from the top of its container and it has a fixed height.

The view car group is the standard distance from the bottom and sides of the container view, and the top is a fixed distance from the divider view.

These descriptions create a view car group that can grow or shrink, based on the height of the screen. The “standard distance” refers to the recommended insets and spacing given by Apple. Since the view car group can change, you need to specify how the component views are related. The Car Info label has enough white space on top and bottom to adjust for the screen height:

The Car Number label is fixed to the top of its container view (the view car group).

Each button is fixed to the bottom of its container view.

The top of the Car Info label is the standard distance from the bottom of the Car Number label, and the bottom is the standard distance from the top of the Previous button.

When the view car group grows or shrinks, the Car Number label and buttons stay fixed. The Car Info label changes height as needed. With some other descriptions, you can specify the entire scene.

With auto layout, you can create these kinds of descriptions, and iOS uses them to figure out how to position and size your views for the current screen size. The system takes care of adapting your interface to different screen heights and orientations. You can even force the system to recalculate if, for example, views are expanded or inserted.

Each relationship is a constraint for how one attribute of a user interface (UI) element is related to an attribute on another. It takes more than one constraint to express all the relationships between two views. For all the power of auto layout, there are only a few new methods and just one class,NSLayoutConstraint, for describing the constraints.

Constraints

The descriptions in the preceding section are constraints on the relationship between views. Sometimes the relationship is contained in the same view, sometimes between siblings, and sometimes between a view and its container. You can even specify relationships between views in different containers. For instance, you can say that the New Car button is the same width as the Previous button.

Pixels and Points

Before looking at constraints, it is important to understand the difference between pixels and points. Pixels are the physical hardware-addressable elements that show individual elements of color on the screen. They determine the resolution of the screen, and the number of pixels in a given area, or pixel density, determines how sharp objects on the screen appear.

To date, iOS units come with two pixel densities: normal and retina. Because retina has twice the pixel density, an image will show up correctly in normal density but at only half the size on retina. There are similar issues for correctly placing other screen elements, such as views. And there are screens with many different pixel densities. Writing code to deal with all possibilities would be a lot of effort.

Instead, Apple uses points, a pixel-independent representation of the drawing area of the screen. They take care of all the hard work for you. Coordinates on the screen, distance between elements, and values for constraints are all expressed in points, not pixels. And images can be provided in both normal and retina versions.

Constraint Relations

The simplest kind of constraint relates a feature of one view to itself, such as a fixed height of 44 points. You can express that constraint in an equation like this (note that this is not Objective-C code yet, just a way to think about constraints):

View1.height == 44.0

A more common relationship is the relationship of an attribute of one view to the attribute of another, such as the top of view 1 is in the same location as the bottom of view 2:

View1.top == View2.bottom

Look carefully at the two pseudo-code constraint relationships. They are not using the assignment operator, =. Instead they are using the equality operator, ==. This is an important part of constraints. They are not an assignment. The system can find a solution by changing either or both sides of the statement. For example, in the relationship above, the system can change both the top of View1 and the bottom of View2. As you will see later, this is a powerful way to build adaptive interfaces, especially as it is possible to indicate which constraints must be satisfied versus a relative ordering of those that the system can change.

In the examples in the previous section, there are places where the constraint relationship adds an offset, typically the standard separator distance. This would be the equation for the bottom of the view car group in the first constraint in the preceding section:

ViewCarView.bottom == ContainerView.bottom - StandardSystemDistance

Constraints define how the attribute of one view is related to the attribute of another view. Attributes are ways to describe view geometry and include the following:

The leading and trailing edges of the view. These are alternatives to left and right when the relationship sense needs to change between left-to-right languages and right-to-left ones such as Hebrew or Arabic. For example, in English, leading is left, and trailing isright. In Arabic, leading is right, and trailing is left. You use these attributes in Chapter 5.

The left, right, top, and bottom edges of the view.

The width and height of the view.

centerX and centerY for the X and Y centers of the view.

The baseline of the view. This is used in views that show text, and is a typographical term corresponding to an imaginary line drawn under the bottom of characters that have no descenders. (When you are writing on a piece of lined paper, the descender is the piece of a letter that goes below the line. For example, a has no descender, but p and g do.)

This is the more general form of the constraint equation:

view1.attribute == (view2.attribute * scaleFactor) + offset

view1.attribute and view2.attribute are the two views and their attributes, scaleFactor is the amount of the second value to use, and offset is a constant added to the relationship. For example, relationship 1 above has two constraints. The first specifies the height of the view. Assuming that the height is 102 points, this is the constraint equation:

addCarView.height == 102.0

Notice that no other view is needed for the relationship. The scale factor is effectively 0.

An example of using the scale factor is doubling the width of a view:

someView.width == someView.width * 2.0

In this case, the offset is 0.

Finally, the relationship does not have to be equal. It can also be one of the following:

Less than or equal to

Greater than or equal to

For example, if you want to give the car info label a minimum height, you could show this with the following:

carInfoLabel.height >= MinimumHeightForContent

The formula is a way to think about how constraints are specified. Though you can make a call that creates the constraints using all the elements of the formula, it is the hardest way to do so. The next section shows an easier way to create constraints.

Creating Constraints

Now that you know what constraints are, how do you create them? You can create them in three ways:

Using Interface Builder (IB)

Using Visual Constraint Language (VCL)

Specifying all the parts of the relationship equation

IB requires the least work to create constraints, VCL requires more work, and specifying the relationship equation takes the most work. You can even have IB automatically create the minimum number of constraints needed for a layout, but you are likely to want to change things. For this chapter, you use IB to create your own constraints by using visual tools.

For the last two ways of creating constraints, you use class methods of NSLayoutConstraint. In VCL, you use strings in a special format to specify how two views are related. One visual description usually results in multiple constraints. When you use the third method to create constraints, you create each part of just one relationship equation in a format that is long and difficult to read.

Exploring Constraints in IB

The best way to see how constraints are created in IB is adding some of your own. To do that, create a new single view application project in Xcode named LayoutTest. Remember, to create a project, you can choose File > New > Project or press Cmd-Shift-N.

When the project opens, select Main_iPhone.storyboard and select the File inspector. You do this either by selecting View > Utilities > Show File Inspector, pressing Cmd-Option-1, or selecting the utilities area and then the left-most icon in the control tab at the top of the utilities area. (InFigure 2-5, the utilities area is indicated by the number 8.)

The Use Autolayout box is checked. By default, storyboards are created with auto layout turned on. You could turn it off by unchecking the box.

Drag a UILabel onto the scene and align it with the lower left Xcode guidelines, as shown in Figure 4-2. Make sure the simulator target is a 4-inch retina iPhone and run the app. You see the label in the lower-left corner.

Figure 4-2 Aligning the label

Stop the app, change the target to a 3.5-inch retina iPhone, and run the project again. The label is gone. To convince yourself the label is still around, use IB to change the top coordinate to 488. You can do this by selecting the label, opening the Size inspector, and changing the Y value.

You can confirm the label is in the correct place by selecting the label, moving the mouse out of the label, and holding down the option key. You should see something like Figure 4-3. The combination of lines and numbers tells you the distance between that edge of the label and the edge of the container. For example, the label is 80 points from the bottom of the screen and 20 from the left, or leading edge.

Figure 4-3 Showing distance to edges with the option key

Run the app again in the 3.5-inch retina iPhone simulator. This time you can see part of the label at the bottom of the screen.

Pixel-Perfect Help

The storyboard is set to use auto layout, so what happened? Xcode was trying to do what you asked. By placing the label at a specific location with a specific width and height, you are telling Xcode that is where you want that UI element. It does not matter how big the device is or what the screen orientation is.

To make sure the element shows up exactly where you want, the compiler generates the appropriate constraints. When you start adding your own constraints, they will take priority. That is, the compiler will not generate any placeholder constraints to override yours.

You may think this is not helpful, but actually it is exactly what you want. By making sure that elements are pixel-perfect until you say otherwise, you can quickly prototype layouts and easily try different combinations of constraints.

To see this, add a constraint for the distance between the label and the bottom of its container. Do this by selecting the label and then choosing Editor > Pin > Bottom Space to Superview, as seen in Figure 4-4.

Figure 4-4 Using the Editor menu to set a constraint

You can tell the new constraint was added in one of three ways. Figure 4-5 highlights each way:

There is a new Constraint item in IB’s left-hand list of view elements.

The selected label on the IB canvas shows an i-beam for the constraint.

The Size inspector for the label shows the constraint.

Figure 4-5 The three ways IB shows constraints

Now run the app, first on the 3.5-inch and then the 4-inch displays. You will see that the label is now the same height from the bottom of the screen on both displays.

Adding Constraints from the Toolbar

The Editor menu is one of three ways to add constraints in IB. The toolbar at the lower right of the IB canvas provides another way. Shown in Figure 4-6, the toolbar is divided into three groups. The first group has only one item and lets you quickly toggle all the view controllers on the canvas between the 4-inch and 3.5-inch screens. The figure shows the 4-inch screen setting.

Figure 4-6 IB toolbar

The third group lets you zoom the contents of the storyboard in and out. It is used for getting an overview of larger storyboards.

The middle group is for constraints. Each of the first three items in that group roughly corresponds to an item in the Editor menu: The first item is for alignment, the second for pinning, and the third for resolving auto layout issues. Resolving issues is covered later in the chapter.

Most of the alignment constraints are relationships between siblings. Two of them are used for centering a single view horizontally or vertically in a container. To see this, perform the following steps:

1. Drag another UILabel into the scene.

2. Double-click the label and change the string to “Center Y.”

3. With the label still selected, click the alignment item in the toolbar to show the alignment popup.

4. Check the boxes for vertical and horizontal centering in the container. (You can see these options checked near the bottom of Figure 4-7.)

Figure 4-7 The alignment constraint popup

5. Open the Update Frames popup and choose to update Items of New Constraints as shown in Figure 4-7.

6. Click the button to add the constraints.

The label moves to the center of the screen and shows two blue i-beams, one for each constraint. Now use the popup to align the leading edges of both labels:

1. Select the Center Y label, then the original label.

2. Open the alignment popup on the toolbar and check Leading Edges.

3. Again select the popup to update frames of new constraints.

4. Add the constraint.

The original label moves over until its left (or leading) edge is aligned with the centered label. In addition, a new constraint i-bar is added between the leading edge of both labels.

The Pin Toolbar Item

The second item in the constraints section of the toolbar has the same items as those in the Editor > Pin submenu. But just like the alignment popup, the pin popup gives you much more flexibility. To see this, add another label and align it to the top leading edge of the container:

1. Add a UILabel to the scene.

2. Select the label and change the name to “Top Label.”

3. With the label still selected, click the Pin item in the middle group in the toolbar to open the pin popup shown in Figure 4-8.

Figure 4-8 The pin constraint popup

4. Use the dropdown triangle in the value boxes to set the Standard Value for the top edge constraint, also shown in Figure 4-8.

5. Now set the distance for the leading edge to the standard value.

6. Set the popup to update the frames of any items with new constraints and add the new constraints.

The new constraints are added and the label moves to the top-left area of the scene.

The third item in the toolbar constraint area is for resolving constraint issues. You will see more on this later in the chapter. The last item of the group is how changes in constraints flow through the hierarchy when views are resized and is beyond the scope of this book.

Changing Constraint Values

Using the toolbar constraint popups is a great way to add both the constraints and any constants such as the standard distance from a container or an offset between two views. But what happens when you need to change those values?

One way is to select the view and open the Size inspector. Try this by selecting the Center Y label. The Size inspector shows you a list of all the related constraints. On the right side of each constraint is a gear that brings up a constraint editing dropdown shown in Figure 4-9. From here, you can delete or edit the constraint. What you can edit depends on the constraint. You will see more detail as you continue through this chapter.

Figure 4-9 Constraints in the Size inspector

Another way to edit constraints is double-clicking on a constraint on the IB canvas:

1. Select Top Label.

2. Make sure the Attributes inspector is selected in the utilities area.

3. There are two constraints, one to the left of the label, one on top. Double-click the left constraint.

After you double-click, two changes happen as shown in Figure 4-10. The first is a quick editor pops up close to the selected constraint. You can see that editor on the left side of the figure. This editor is useful for quickly changing attributes shared by all constraints. On the left side, the Attributes inspector adds any constraint-specific editable items. As you work through the chapter, you learn more about the generally editable attributes as well as items associated with some types of constraints.

Figure 4-10 Popup constraint editor

In addition to editing constraints, you can use the details to verify that the constraints are giving you the correct positioning for the current screen size and rotation. Distances between views as well as edge alignments are also shown by using the Option key, just as you did previously.

This is because the Option key shows you the distances between the selected view and the view currently under the cursor. In Figure 4-3, there was only one other view...the superview. Now that you have more than one view, try selecting one of them and then hold down the Option key and move the mouse over other views. You will see the information change as you move between sibling views and the parent, or superview.

Dragging Out Constraints

The final way to specify constraints in IB is Ctrl-dragging (or right-mouse-button-dragging) from a view. When you complete the Ctrl-drag, IB offers a popup with possible choices for constraints. You can select one constraint or hold down the Shift key to select multiple constraints.

Try Ctrl-dragging from the Center Y label toward the right edge of the scene and let the mouse up soon after it exits the label. You see a constraints popup like the one on the left side of Figure 4-11. The right side of the figure shows the result of Ctrl-dragging from the bottom label and releasing in the Center Y label.

Figure 4-11 The Ctrl-drag constraint popup

Each popup shows the constraints that make sense given the direction of the drag and participating views. The left side of Figure 4-11 shows only two possible constraints: one from the trailing edge of the label to the trailing edge of the container of that label and the other to center the label in a vertical direction.

The right side of Figure 4-11 shows more options because the views are siblings. The first two sections of the popup are all constraints based on vertical relationships. The first section sets a vertical distance constraint. The next section keeps the original label at the same distance and sets how the positioning of the views is related, aligning their left, center, or right locations. The third section is not related to either vertical or horizontal relationships. Instead, it sets views to the same width or height.

In both popups, you see a white circle in front of a constraint. This indicates an existing constraint between the views. For example, on the left side of Figure 4-11, the dot is for the labels’ vertical centering constraint. On the right side, the white dot says there is already an align-left constraint between the two views.

Now try clicking and dragging in a diagonal line from the label on the bottom of the scene and releasing in the label on the top. When you do this, you get a constraint popup with a much larger selection of constraints, as seen in Figure 4-12.

Figure 4-12 Constraints for a diagonal drag

Ctrl-dragging is the fastest way to add constraints. The list of constraints shown in the menu depends on a combination of three things:

The general direction of the drag

The distance dragged

The view where the drag ended

Xcode uses these three things to generate a likely list of possible constraints. In general, drags in a roughly horizontal direction show horizontal constraints. Drags in a vertical direction show vertical constraints, and diagonal drags show both types of constraints. Double-clicking the newly created constraint lets you quickly modify constants or other constraint-specific information.

Now it is time to use these skills and add constraints to CarValet.

Perfecting Portrait

There are models of the iPhone and iPod touch with different screen heights. Auto layout lets you create one set of constraints that works for all geometries and sizes. Right now, your layout is pixel-perfect for a 4-inch portrait display. In this section, you add constraints so it works with both 4-inch and 3.5-inch portrait displays.

Designing and adding constraints are part of the flow of designing and creating your user experience (UX). Figure 4-13 shows the general phases. First, you design your screen mockups, usually as part of the initial app specifications. When you start development, you do simple initial layout without using constraints. This is what you have done up to now with CarValet. In practice, initial designs tend to be modified during implementation, so it is best not to invest too much time creating constraints until the interface is fairly stable.

Figure 4-13 Constraint editing cycle

Eventually you start designing and adding the constraints. As you test your interface in various screen sizes and orientations, you usually find some problems. This gives you a cycle of adding some constraints, trying them, debugging, tuning, and then adding more constraints.

At some point, you have all the constraints you need as part of a fully functional app. At that point, you ship the app, as well as do any ongoing maintenance...and start designing the next release.

Thinking in Constraints

If you want to effectively use constraints, you need to change the way you think about designing and laying out your interface. The typical way is to think about the rectangles enclosing view elements in a coordinate system. Design is a matter of translating the look into the right coordinates and adding any code or additional layouts to adjust the look for different screen sizes and orientations.

With constraints, you think about your interface in a completely new way: How do the visual elements on your screen relate to each other? The goal is to find a set of constraints (relationships between views) that enable iOS to adapt the views to any of the supported screen sizes and orientations. It is not just how one view relates to another but also how to group views and how those groups relate. This can include relationships of views in one hierarchy to views in another.

Although this sounds complex, the key is to focus on the relationships. The constraints come from those relationships. And the easiest way to express the relationships is in language.

Before you start a design, it is important to understand that the set of constraints for a screen must meet two conditions. First, the constraints should combine to specify one and only one layout for a given screen size—that is, they should not be ambiguous. Second, the constraints must notconflict.

With conflicting constraints, there is no way to satisfy the highest priority constraints. Each constraint has a priority between 0 and 1000. 1000 is the default value and means the constraint must be satisfied. For instance, the Previous button cannot be both a fixed width at a priority of 1000and a width that adapts to content also at a priority of 1000. Reducing the priority on either constraint or removing one constraint resolves the conflict. Conflicts cause runtime exceptions that might crash your app. Xcode usually gives warnings about possibly conflicting constraints, usually as you develop, as well as during compilation.

Ambiguity can be harder to find at design time. Unlike conflicts, the constraint system can position the affected views. However, it can position them in more than one way. A typical way ambiguity shows up is that when you change orientation and then change back, one or more views are not in the same place they were before the rotation.

As you will see when you start adding constraints, IB provides robust tools to identify both conflicts and ambiguity.

What Makes a Complete Specification

How do you know when you are done with your layout? For auto layout to unambiguously position all the views in an interface, it needs to find an origin and size for every view. To do that, every view must be part of one or more relationships that specify four constraints: two for the system to calculate the horizontal position and size, and two for the vertical position and size.

As you saw earlier in this chapter, constraints can be built using many parts of the view geometry. Table 4-1 shows what constraints unambiguously specify the Total Cars label. The completeness table is another example of an excellent tool for design. You can create tables like this for any level in the view hierarchy of a scene. Although there can be cross-hierarchy relationships, you should focus on checking completeness for one level of a hierarchy before moving deeper to the next one. As you will see later, IB shows constraints with problems in orange and uses blue for complete ones.

Table 4-1 Constraint Completeness for the Total Cars Label

A good rule of thumb is to start checking completeness for the children of the main view, and after that is done, move on to checking the hierarchies of each child. In computer algorithm terms, you perform a depth-first traversal.

The Total Cars label can act as an anchor view—that is, a view with completely specified constraints for any given screen size, usually near an edge or edges of the screen or group. You can use it to help specify other views, such as the New Car button. When designing constraints, looking for anchor views is a good starting point.

As you look at the constraints, you might wonder how the system knows how to set the width and height of the label—especially since you could change the text of any label at runtime.

Intrinsic Content Size

The content of certain UI elements has a natural size. For images, it is the size of the image; for labels, the amount of space required to display the text in the current font; switches have their own size, and so on. This natural, or intrinsic, size is used by the constraint system when figuring out the width and/or height of a view.

In Table 4-1, both the width and height have an intrinsic value: the amount of space required to show the text for the label in the font used by the label.

UView includes an intrinsicContentSize method returning a CGSize—that is, a width and a height. The default is to return UIViewNoIntrinsicMetric—that is, no intrinsic value, for each component. Some view system classes that override the method include UILabel,UIImageView, UISwitch, and UIButton.

Adding/Viewing Cars: Designing and Implementing the Constraints

Before you added any constraints to LayoutTest, you moved the label, ran it on a 3.5-inch screen, and only saw part of the label. Figure 4-14 shows CarValet running on the smaller screen. This is because Xcode adds compile time constraints for any views you have not constrained. These added constraints are just enough to make sure your interface matches exactly what is on the IB canvas, resulting in the bottom row of buttons being cut off. You need to design a set of constraints that works on both screen sizes, something you could do as you design your UX.

Figure 4-14 CarValet on a 3.5-inch screen

The following is a good process for integrating constraints into the design of an interface:

1. Specify what the user can do on the screen (that is, what the behaviors are).

2. Choose visual elements that support the behaviors and create a rough layout.

3. Break up the visual elements into relevant groups, based on screen functionality. There might be only one group if the behavior is simple.

4. Do an initial design of how the visual elements are arranged in the groupings.

5. Design how the groupings relate to each other in the different layouts: portrait and landscape in both 3.5- and 4-inch screen sizes. For now, you look at only a general solution to landscape, and you work on a more detailed design later.

6. Iterate through steps 3, 4, and 5 until you have something that works on the target layouts. Sometimes this may change steps 1 or 2.

7. Express the constraints in natural language.

Steps 1 and 2, and possibly 3 and 4, are part of any UX design; the rest are constraint-specific.

You designed the scene behaviors in Chapter 3 (step 1). The interface elements already exist (step 2), and you have already effectively grouped the scene into three parts (step 3):

An add car group

A separator view

A view car group

The separator view is not connected with any behaviors. It is the kind of visual element used to support visual clarity. Other kinds of nonbehavioral elements can provide decoration or other ways of potentially delighting the customer. The key is to keep these elements to a minimum. Think carefully about each one and be clear on why it is being added.

In a normal project flow, designing the constraints along with groups of views would be done before writing any constraint-related code. Ideally, it is done before laying out the scene, though more often it is done after the layout becomes stable. Although early design is not always possible, and the scene might be modified as the app progresses, doing more upfront design work can save a significant amount of time laying out the interface, as well as in debugging constraints later on.

The Three Add/View Car Groups

Modifying your add/view scene to effectively use constraints for portrait is a good exercise in adding constraints to an existing scene. It also gives some practice in designing the constraints, solving interim problems, and learning other techniques you can use for your own projects.

There are only two views in the add car group, and they each have simple relationships. The Total Cars label is at the top on the leading (or, in English, left) side. The bottom of the New Car button is attached to the bottom of the area and aligned with the leading edge. This layout should work for both portrait and landscape, with the only difference being how wide and tall the area is.

The separator view is even simpler. It is a 2 points high (portrait) or wide (landscape) line that separates the add and view areas. It stretches across the view along the appropriate axis for portrait or landscape. The separator is visually halfway between the add and view car groups.

There is no direct way of specifying that an attribute of a view is halfway between two other views, so you have three basic options here:

If the attribute of the halfway view is between two views with fixed positions on the relevant axis (or axes), you can use a spacing constraint between the closest appropriate edge of a fixed view and the edge of the separator. For the vertical axis, the constraint would be from the top to bottom or the bottom to top edges. The constant value of the constraint corresponds to the distance.

You can insert a new container view that is pinned to the relevant sides of the two views, put the halfway view inside the new container, and set a constraint to center it horizontally and/or vertically in this new container.

You can calculate the constraint yourself at runtime and either update an existing constraint or add a new constraint to the appropriate container view. This might involve removing some of the automatic constraints that IB added or even ones you added in code.

In this case, you can use the first solution because the top of the add view area is a fixed distance from the top of the container. And as you will see, the view car area has a variable height based on the height of the screen. The distance from the bottom of the add car group to the separator is the same as the distance from the separator to the top of the view car group.