Hour 16. Building Responsive User Interfaces

You can use almost every iOS interface widget available, create multiple views and view controllers, add sounds and alerts, write files, and even manage application preferences, but until now, your applications have been missing a very important feature: responsive interfaces. The ability to create interfaces that display correctly regardless of your iDevice’s screen size or orientation is one of the key features that users expect in an application—and the key target of responsive interface design.

This hour’s lesson explores the Xcode Auto Layout system and a purely programmatic way of adding rotatable and resizable interfaces to your apps.

As you read this hour’s lesson, an important fact to keep in mind is that there are many different ways to solve the problem of responsive interface design. What works best for you may be entirely different than what I describe here.

Over the past few years, Apple has gone wild with new device sizes and shapes. Does that mean you need a different storyboard for every single device variation? Nope! The iOS Auto Layout system makes it easy to adapt to different resolution displays and change your interface layout as your device resolution changes.

Although you should definitely plan to accommodate all sizes of the iPhone screen in your iPhone apps, the decision to handle rotation is entirely up to you. Consider how the user will be interfacing with the app. Does it make sense to force a portrait-only view? Should the view rotate to accommodate any of the possible orientations the phone may assume? The more flexibility you give users to adapt to their own preferred working style, the happier they’ll be. Best of all, enabling rotation is a simple process.

When an iOS device wants to check to see whether it should rotate your interface, it uses the supportedInterfaceOrientations method in your view controller. The implementation of supportedInterfaceOrientations just returns a value that describes the supported orientation. To cover more than one orientation, you just return the list of constants you want to use, separated by the | character. With the initial releases of Xcode 6.x, accessing these constants requires us to tack rawValue on the end and to wrap the whole thing in a conversion to an integer—hopefully this nuttiness goes away in the future.

There are seven screen orientation support constants, as listed here:

Portrait: UIInterfaceOrientationMask.Portrait

Portrait Upside-Down: UIInterfaceOrientationMask.PortraitUpsideDown

Landscape Left: UIInterfaceOrientationMask.LandscapeLeft

Landscape Right: UIInterfaceOrientationMask.LandscapeRight

Any Landscape: UIInterfaceOrientationMask.Landscape

Anything But Upside-Down: UIInterfaceOrientationMask.AllButUpsideDown

Anything: UIInterfaceOrientationMask.All

For example, to allow your interface to rotate to either the portrait or landscape left orientations, you implement supportedInterfaceOrientations in your view controller with the code in Listing 16.1.

LISTING 16.1 Activating Interface Rotation

Click here to view code image

---

override func supportedInterfaceOrientations() -> Int {
    return Int(UIInterfaceOrientationMask.Portrait.rawValue) |
           Int(UIInterfaceOrientationMask.LandscapeLeft.rawValue)
}

---

The return statement handles everything. It returns the combination of the two constants that describe landscape left and portrait orientations.

At this point, take a few minutes and go back to some of the earlier hours and modify this method in your view controller code to allow for different orientations. Test the applications in the iOS Simulator or on your device. For iPhone apps, try switching between devices with different horizontal and vertical dimensions displays.

Some of the applications will probably look just fine, but you’ll notice that others, well, don’t quite “work” in the different screen orientations and sizes, as shown in Figure 16.1 (ImageHop, from Hour 8, “Handling Images, Animation, Sliders, and Steppers”).

Everything we’ve been building has defaulted to a portrait design and, for the most part targeted a very specific screen height and width. So how can we create interfaces that look good regardless of the orientation and size of the screen? We obviously need to make some tweaks.

Using Auto Layout should be the starting point for all interfaces. If you can successfully define portrait and landscape modes in a single view in the IB editor, your work is done.

Unfortunately, Auto Layout alone doesn’t work well when there are many irregularly positioned interface elements. A single row of buttons? No problem. Half a dozen fields, switches, and images all mixed together? Probably not going to work.

For example, to detect when the interface rotates, we can implement the method didRotateFromInterfaceOrientation in our view controller. The view controller variable property interfaceOrientation will tell us the current orientation of the interface by containing one of these four constants:

Portrait: UIInterfaceOrientation.Portrait

Portrait Upside-Down: UIInterfaceOrientation.PortraitUpsideDown

Landscape Left: UIInterfaceOrientation.LandscapeLeft

Landscape Right: UIInterfaceOrientation.LandscapeRight

The drawback to doing everything in code is that you are doing everything in code. It becomes very difficult to prototype interface changes and visualize what your final interface will look like. In addition, it is harder to adapt to changes in the future.

This means that you can define two views in a single scene that look exactly the way you want, but it also means that you must keep track of separate IBOutlets for each view. Although it is certainly possible for elements in the views to invoke the same IBActions, they cannot share the same outlets, so you’ll potentially need to keep track of twice as many UI widgets within a single view controller.

Of course, you’re welcome to build your application in whatever manner suits you. I recommend waiting until Hour 23 before starting a complex app that aims to take advantage of all of Apple’s unique device screen sizes.

Leading: The “front” or left side of an object.

Trailing: The “back” or right side of an object.

Superview: The view that contains an object. In our examples, this is the “view” that makes up the scene itself.

For example, try adding a button to the window in the Empty.storyboard file; make sure that it is located toward the top-left side of the view and that you’ve resized the button slightly. In its initial state, your button layout doesn’t display any constraints. That doesn’t mean that your layout won’t use them; it just means that Xcode will automatically add what it feels is appropriate when you build your project.

To add constraints that you can actually work with and adjust, you’ll use the Editor, Resolve Auto Layout Issues, Add Missing Constraints menu option (as shown in Figure 16.2). This adds constraints for the currently selected object. To add constraints to all objects in a scene, you can choose Add Missing Constraints under the All Views in View Controller heading instead. Go ahead and try either of these options on your scene with the button.

After you’ve added constraints, you’ll notice two visual changes. First, there are blue lines (representing the constraints) attached to your UI objects. In addition, a new Constraints entry appears parallel to the button in the document outline hierarchy, as well as a Constraints item within the button object itself, as shown in Figure 16.3.

What constraints are added depend on where the object is in relation to its containing view. When you use Xcode to automatically add constraints, it does its best to choose what makes the most sense. If you position a button near the bottom of the view and add suggested (or missing) constraints, for example, Xcode will add a constraint for the distance between the bottom of the button and the bottom of the view.

Constraints, however, are more than just entries that tie an object to the view it is within. They can be flexible, ensuring that an object maintains at least or at most a certain distance from another object, or even that two objects, when resized, maintain the same distance between one another.

Constraints that set a specific size or distance between objects are called pinning. The flexibility (or inflexibility of a constraint) is managed by configuring a relationship.

This brings us to the second constraint object in the document outline: constraints on the object itself, not on its positioning. When you’ve resized a user interface (UI) element or set constraints on how the content within it is positioned, Xcode will add a constraint object inside the UI element entry in the document outline. These constraints determine the width or height of the element (or both). Not surprisingly, when you’ve got dozens of components in your UI, you’ll have lots of constraints in your document outline.

Use the Edit button to the right side of each constraint to select and edit it. For example, if you pick a width constraint and click Edit, Xcode shows a popover with simple settings for adjusting it, as shown in Figure 16.5.

For full editing capabilities, however, you’ll want to double-click the constraint, which jumps you into the Attributes Inspector. Here you can see and adjust all the details of the constraint, as demonstrated in Figure 16.6. The Attributes-Inspector approach is what I’ll be showing throughout the hour.

The First Item and Second Item drop-downs are used to configure what part of each object involved in a constraint is being considered. A button that is constrained to the top layout guide, for example, might have the constraint set on its top or bottom—or maybe even its center. In general, these aren’t something you’ll often touch, because the correct pieces parts are chosen for you when you create the constraints.

The Relation drop-down determines what the constraint is trying to do. Is it trying to keep a distance or size equal to a value? Greater than or equal to it? Less than or equal? You choose the relation that gives your interface the flexibility you need. With each relation, you can also set a constant. This is a measurement, in points, that the relationship will be maintaining.

You’ll also notice that a Priority value, Multiplier, a Placeholder check box, and a Standard check box (sometimes) appear in the editor. The Priority slider determines how “strong” the constraint relationship is. For example, there may be instances when multiple constraints must be evaluated against one another. The priority setting determines the importance of any given constraint. A value of 1000 is a constraint that is required. If you move the slider, Xcode shows a description of what to expect at a given constraint priority.

The multiplier is exactly what its name suggests—a value that is used for multiplying. Multiplying what? The second item involved in a relationship. Imagine you have two buttons that include a constraint for their widths to be equal. If you’d like the first button’s width to be maintained as twice as large as the second, you would add a multiplier of 2, as follows:

Button1.width = 2 (the multiplier) × Button2.width

The Standard check box (not visible in Figure 16.6) lets Xcode use its internal database of spacing to set the recommended space between two objects. This, in many cases, is preferred because it ensures a consistent interface.

The last setting, the Placeholder check box, is used if you plan to resize or move the UI object in your code. If you check this option, you can use Auto Layout tools to set up your UI element, but the constraints will be removed when your application runs.

In a few minutes, we’ll make use of the editor to configure a few relationships. Trust me, it makes more sense once you get started.

These settings control how closely the sides of an object “hug” the content in the object and how much the content can be compressed or clipped. Imagine a button that you want to expand horizontally, but not vertically. To allow horizontal expansion, you’d set horizontal hugging as a low priority. To keep it from growing vertically, you set vertical hugging to a high priority.

Similarly, the content (the button label) should not be compressed or clipped at all, so the content compression resistance settings for both horizontal and vertical compression should be very high priority.

You will not often need to adjust these settings beyond their defaults, which IB adds for you.

For example, we’ve been looking at a button in the Empty.storyboard. We added the button, added the constraints, and everything was fine. Now, try dragging the button to a new position in the window and see what happens. As soon as you drag the button, you’ll see constraints appear drawn in orange, along with a dotted line where your button was originally located, as shown in Figure 16.7.

The solid lines (and numbers on the lines) show the changes in the original constraints. A +5 on a vertical constraint, for instance, means the object has shifted down 5 points from the original constraint. A –5 on a horizontal constraint indicates a shift to the left. The dotted line shows the frame of the original object.

What’s important to understand here is that even though you’ve moved the object in IB, the original constraints remain—so your object is now considered “misplaced” in Xcode.

In addition to highlighting constraints in another color, Xcode also shows Auto Layout errors in the document outline. When you moved the button an orange indicator appeared by the scene in the object hierarchy; you can see this in Figure 16.7. To get a description of the error, click the indicator icon in the document outline. The display refreshes to show the error, as shown in Figure 16.8.

To fix the error, click the error indicator icon beside the UI object with an error that you want to fix. Xcode displays a list of possible fixes. Try this with the button example. Your display should resemble Figure 16.9.

You have three options for automatically fixing placement errors:

Update Frame: Moves the control so that it fits the constraints that are defined. In the case of the button example, this puts it back where it came from.

Update Constraints: Changes the existing constraints to match the current positioning of the object.

Reset to Suggested Constraints: Adds new constraints to the object (eliminating the old) to match its current position. This uses the best constraints for the current position (in contrast to Update Constraints, which changes the original constraints to fit, even if they aren’t the best choice for the position).

Choose Update Constraints or Reset to Suggested Constraints and you should be back in business. Check the Apply to All Views in Container check box to apply to all similar errors, if desired. Click Fix Misplacement to update the storyboard accordingly.

Although this scenario (in my opinion) is the most common that you will encounter, other constraint errors are possible. In some cases, you may have multiple conflicting constraints (two constraints pinning the height to different values, for example)—in which case, you’ll be prompted to delete one of the conflicts.

On the other end of the spectrum, if you don’t have enough constraints to determine an object’s position, you will see an error for missing constraints. Clicking through the error indicators will present you with the option to add the missing constraints, as shown in Figure 16.10.

Before we put what we’ve learned into practice, I want to make one thing clear: There is no “one way” to build interfaces with Auto Layout, but there is a mindset that will be helpful as you build your own designs. Specifically, start by identifying the interface elements that you want to anchor somewhere on the screen, regardless of orientation or screen size. From there, begin looking for the relationships between those elements and the other objects that make up your interface. Building relationships between objects, rather than trying to tie each element to specific coordinates within a view, is a good tactic for successful UI design.

1. Open a copy of the Empty.storyboard file and add a button to the scene. Resize the button slightly so that it is larger than the default size.

2. First, we’ll pin the width and height. Without a width and height set, the object won’t know whether it should grow, shrink, or move to center itself during a rotation. Pinning a width and height makes centering unambiguous. Select the button, then choose Editor, Pin, Width from the menu bar.

3. Reselect the button, and then choose Editor, Pin, Height. Yes, you have to keep reselecting the button. Annoying, isn’t it? You’ve now set a width and height that will be maintained regardless of the orientation.

4. To set the Align constraints, select the button, then choose Editor, Align, Horizontal Center in Container.

5. Repeat the step 5 alignment, this time aligning to the Vertical Center in Container.

6. For the last step, select the button one more time, then choose Editor, Resolve Auto Layout Issues, Update Frame. Your layout should now be finished and resemble Figure 16.12.

Switch to the assistant editor (View, Assistant Editor, Show Assistant Editor), and select Preview from the path bar above the editor (click where it initially shows Automatic). Use the control at the bottom of the preview display to rotate the display; use the + button in the lower-left corner of the preview to add additional device previews. Assuming your constraints are correct, the button should also properly center itself regardless of your settings, as demonstrated in Figure 16.13.

That was pretty simple, wasn’t it? Of course, not all your applications will consist of just a single button (only the best ones). For that reason, we cover a few more examples, starting with resizing controls.

1. Drag a button to the storyboard, positioning it at the bottom center of the view using the guides that appear while dragging.

2. Resize each side of the button by dragging toward the side of the view, and then release when you see the blue guide appear.

3. Select the button, and then from the menu bar, choose Editor, Resolve Auto Layout Issues, Add Missing Constraints.

By using the guides in steps 1 and 2, Xcode knows that when it adds the missing constraints, it should use the default margins for pinning the button. You should see three constraints that anchor to the side and bottom margins of the view, as shown in Figure 16.14.

The constraints that have been created are a good start for the button. These ensure that the sides of the button are always an equal distance from the sides of the view, regardless of the orientation. The same goes for the distance from the bottom of the view to the bottom of the button.

Next, add two text views to the scene:

1. Drag two text views to the scene, stacking one on top of the other.

2. Resize the text views to fill the scene horizontally, until the blue guides appear at the margins.

3. Size the text views vertically until the guides appear to keep the views from overlapping the button, one another, or the top margin of the scene.

4. Select both text views. And then from the menu bar, choose Editor, Resolve Auto Layout Issues, Add Missing Constraints.

5. Set the background color of the text views to something other than white so that they are easier to see. Your finished view should look like Figure 16.15.

Depending on how you added and sized for your text views, you’ll notice that each of them has a variety of constraints that tie them to the sides of the screen, the top (or bottom) of the screen, and maintain spacing between each other and the button.

You’ll also see that one of the text views will have a height constraint applied. We’ll be working with this constraint in a few minutes, so find it now.

Why is there only one height constraint? Because as long as one is defined, the other text view can have a relative height calculated from all the other constraints. (If this sounds confusing, think of two lengths of string that together equal 1 foot. If one string is 7 inches long, you can calculate the second length of string... I hope.)

Specifically, you need to accomplish these things:

1. Pin the height of the button so that it can’t get squished by one of the text views.

2. Choose the text views to be the first to shrink when the size changes. We set this view so that its height is greater than or equal to the smallest size we want it to reach. I will use the top view for this purpose and set its minimum height to 100 points or greater.

3. Set a fixed height on the bottom text view (I’ll use ~250 points) so that it doesn’t change size. But, we need to set its priority to less than 1000 (the default). This lets the text view change sizes in an extreme situation. That “extreme situation” would otherwise occur in landscape mode where the top view would try to maintain a height of 100 points but the bottom view’s fixed height of 250 would force a condition where both can’t hold.

Begin by selecting the button. Then, from the menu bar, choose Editor, Pin, Height. Simple enough!

Next, take a look at which of your text views already has a height constraint. We need to make sure that both do. So, select the one that doesn’t and choose Editor, Pin, Height. You’re now ready to add some constraint logic.

Select the top text view; then use the Size Inspector to select and edit the height constraint.

Using the Relation drop-down, choose Greater Than or Equal. Set the constant to 100 (the text view must be 100 points in height or greater) and leave the priority alone. Your configuration should look like Figure 16.16.

Now the top text view will shrink when it needs to, but it can also grow; in fact, until a constraint is set on the bottom text view, it can grow too large, pushing the bottom text view until it is too small in any orientation.

Select the bottom text view and again edit its height constraint. (Add one if it isn’t already there.) Make sure that the relation is set to Equal with whatever constant Xcode added, as shown in Figure 16.17. This time, however, set the priority down to 999. This makes the constraint turn into a dotted line (visible in Figure 16.17) showing that the constraint will try to be maintained, but, if necessary, it can resize to avoid violating other constraints.

Go ahead and try resizing the view between iDevice screen sizes and rotating to landscape mode. Everything should work like a charm, with the top text view resizing when needed and the bottom text view resizing when it absolutely has to.

Create a new copy of the Empty.storyboard document, and then drag a new button into the middle of the display. Size the button to be a bit under 1/3^rd of the screen width (doesn’t matter what the simulated size of the display is)—you’re going to be placing three in a horizontal row. Next, set a background color for the button’s view so you can more easily see the width.

Copy your button to create a total of three, and label them Button A, Button B, and Button C. Use the guides to align them in the vertical center of the display, as seen in Figure 16.18.

You now know enough to make one of the buttons resize, but how could we constrain them so that all the buttons resize to fill in the screen in landscape mode? These are the steps constraints that I came up with:

1. Start by manually positioning the buttons where you’d like them—using the guides wherever possible.

2. Align all the buttons to the vertical center in the container. This keeps them centered vertically on the screen.

3. Align the middle button to the horizontal center of the container; it should always remain in the middle of the screen.

4. Pin the Leading Space of Button A to the superview (the edge of the view).

5. Pin the Trailing Space of Button C to the superview.

6. Pin the Horizontal Spacing between Button A and Button B.

7. Pin the Horizontal Spacing between Button B and C. (If we stopped here, the center button (Button B) would stretch while the other buttons would stay the same size.)

8. Pin the buttons so that they all share the same width. (Select all the buttons, and then choose Editor, Pin, Widths Equally.)

9. Resolve any errors that appear by choosing Editor, Resolve Auto Layout Issues, Update Constraints.

Use the Editor menu or the IB editor buttons to add these constraints to your storyboard; you should know how to do it by now. There is no need to adjust the priority or relationships in this case. Your finished layout will hopefully be similar to Figure 16.19. (One of the = constraints may be on a different button. This is fine.)

Switch to the assistant editor and open a preview. When you view your design in landscape or on varying devices, all the buttons should resize equally and fill in the space across the screen, as shown in Figure 16.20.

In cases like this, consider implementing the UI (or portions of it) completely in code. But, what about the nice and neat drag-and-drop approach? Well, using code isn’t as convenient as drawing your interface in IB, but it isn’t difficult. We’re going to move to a project that is the exact opposite of our last few examples—rather than building a responsive interface without code, we’re going to only use code to create an interface.

In the portrait orientation, the buttons are drawn with the label sandwiched between them. In landscape, the buttons move closer to the bottom, and the label repositions above them. The final output will resemble Figure 16.21.

Take note that the positioning of the buttons and the label cannot be handled in Auto Layout (at least not with our current toolset). When you encounter issues that can’t be solved in Auto Layout, there’s no harm in coding your way out of the forest.

To handle the rotation and resizing of the objects, we use the bounds of the scene’s view. This gives us the width and height of the device corresponding to whatever orientation it is in. We then use these values to position the UI elements on the screen. By basing the positioning on the bounds, the size of the device screen and orientation are largely irrelevant, as you’ll soon see.

We also implement a method: handleButton, which updates the onscreen label to show the title of a button that was tapped. Like the variables, this won’t be declared using IB, but we’ll be using it just like an IBAction. We also add two additional methods, initInterface and updateInterface, to handle setting up and updating the interface, respectively. These will be triggered by a change in orientation, so our next step is to set up the project to properly handle orientation changes.

LISTING 16.2 Supporting All Interface Orientations

Click here to view code image

---

override func supportedInterfaceOrientations() -> Int {
    return Int(UIInterfaceOrientationMask.All.rawValue)
}

---

Edit ViewController.swift, adding the constant definitions below the class block, as shown here:

Click here to view code image

let buttonA: UIButton = UIButton.buttonWithType(UIButtonType.System) as UIButton
let buttonB: UIButton = UIButton.buttonWithType(UIButtonType.System) as UIButton
let theLabel: UILabel = UILabel()

Notice that I’m initializing the objects, not just declaring them. The buttons are created with the type UIButtonType.System—the standard type of button we get when adding buttons through Interface Builder.

By keeping the display logic separated from the initialization logic, we can build a method that can be invoked at any time to update the interface. This method, aptly named updateInterface, is called at the end of the initInterface and anytime interface rotation is sensed.

Add the initInterface method from Listing 16.3 to ViewController.swift.

LISTING 16.3 Prepare the Interface (But Don’t Display It Yet)

Click here to view code image

---

 1: func initInterface() {
 2:     buttonA.addTarget(self, action: "handleButton:",
 3:         forControlEvents: UIControlEvents.TouchUpInside)
 4:     buttonA.setTitle("Button A", forState: UIControlState.Normal)
 5:
 6:     buttonB.addTarget(self, action: "handleButton:",
 7:         forControlEvents: UIControlEvents.TouchUpInside)
 8:     buttonB.setTitle("Button B", forState: UIControlState.Normal)
 9:
10:     theLabel.text="Welcome"
11:
12:     updateInterface()
13: }

---

This might be the first time we’ve manually created a number of UI elements, but because you’ve been working with these objects and adjusting their variable properties for hours, this code shouldn’t seem completely foreign.

Lines 2–3 set the action for buttonA. The addTarget:action:forControlEvents method configures what will happen when the Touch Up Inside event occurs for the button—in this case, calling the method handleMethod. This is exactly the same as connecting a button to an IBAction in IB.

Line 4 sets the title for the button to Button A.

Lines 6–9 repeat the same process for Button B (buttonB).

Lines 10 initializes the label (theLabel) with the default text Welcome.

Lastly, line 14 invokes the updateInterface method so that the newly defined user elements can be placed on the screen. So, what do we do now? Implement updateInterface.

For example, consider this code snippet:

Click here to view code image

let screenWidth: CGFloat = view.bounds.size.width;
let screenHeight: CGFloat = view.bounds.size.height

This grabs and stores the current screen width and height in the constants screenWidth and screenHeight. The dimensions and position of UI objects are determined by their frame, which is a variable of type CGRect. To set the frame of a button named theButton so that it filled the top half of the screen, I’d write the following:

Click here to view code image

theButton.frame=CGRectMake(0.0,0.0,screenWidth,screenHeight/2)

The first two values of CGRectMake (which create a CGRect data structure) set the origin point at 0,0. The second two parameters determine the width and height of the CGRect. Using screenWidth sets the button to the same width of the screen, and screenHeight/2 sets the height of the button to half the height of the screen. In an actual implementation, you want to include some margin around the edges. This is why you’ll see +20 and other values tacked onto my coordinates. Speaking of which, go ahead and implement updateInterface, as shown in Listing 16.4. When you’re done, we step through the code.

LISTING 16.4 Implementing updateInterface

Click here to view code image

---

 1: func updateInterface() {
 2:     let screenWidth: CGFloat = view.bounds.size.width;
 3:     let screenHeight: CGFloat = view.bounds.size.height
 4:
 5:     for subview in view.subviews {
 6:         subview.removeFromSuperview()
 7:     }
 8:
 9:     if interfaceOrientation == UIInterfaceOrientation.Portrait ||
10:         interfaceOrientation == UIInterfaceOrientation.PortraitUpsideDown {
11:             buttonA.frame=CGRectMake(20.0,20.0,screenWidth-40.0,
12:                                     screenHeight/2-40.0)
13:             buttonB.frame=CGRectMake(20.0,screenHeight/2+20,
14:                                     screenWidth-40.0,screenHeight/2-40.0)
15:             theLabel.frame=CGRectMake(screenWidth/2-40,
16:                                     screenHeight/2-10,200.0,20.0)
17:     } else {
18:         buttonA.frame=CGRectMake(20.0,60.0,screenWidth-40.0,
19:                                     screenHeight/2-40.0)
20:         buttonB.frame=CGRectMake(20.0,screenHeight/2+30,
21:                                     screenWidth-40.0,screenHeight/2-40.0)
22:         theLabel.frame=CGRectMake(screenWidth/2-40,20.0,200.0,20.0)
23:     }
24:
25:     view.addSubview(buttonA)
26:     view.addSubview(buttonB)
27:     view.addSubview(theLabel)
28:
29: }

---

Lines 2–3 grab and store the current screen size in screenWidth and screenHeight.

Lines 5–7 loops through all the interface elements in our view, and removes them. This clears out our current interface settings prior to setting their new sizes and locations.

Lines 9–10 check the interfaceOrientation of the view controller, and, if it is in one of the portrait orientations, lines 11–16 are executed. Otherwise, lines 18–22 are evaluated. These blocks both have the same purpose: defining the frame for each of the UI elements (buttonA, buttonB, and theLabel).

Lines 11–16 define positions for the buttons so that there are margins on the edges of the screen and a space in the middle for the label. Lines 18–22 position the buttons lower on the screen and put the label at the top. The margins and spacing I used is completely arbitrary. You can try changing these values around to see what effect they have.

Finally, lines 25–27 add the buttons and label to the view so that they are visible onscreen.

Everything is now in place for the interface, but we need to take care of three small tasks before the project is complete. First, we need to make sure that the interface is drawn when the application first loads. Second, the interface must update when an orientation change occurs. Third, we need to implement handleButton to update the label when the buttons are pressed.

LISTING 16.5 Initializing the Interface When the Application Loads

Click here to view code image

---

override func viewDidLoad() {
    super.viewDidLoad()
    initInterface()
}

---

We’re getting closer. The application will now initialize and display the interface, but it still can’t adapt to a change in orientation.

Add didRotateFromInterfaceOrientation to ViewController.swift, as shown in Listing 16.6.

LISTING 16.6 Handling Rotation in didRotateFromInterfaceOrientation

Click here to view code image

---

override func didRotateFromInterfaceOrientation
        (fromInterfaceOrientation: UIInterfaceOrientation) {
    updateInterface()
}

---

LISTING 16.7 Handling Button Touches

Click here to view code image

---

func handleButton(theButton: UIButton) {
    theLabel.text = theButton.currentTitle
}

---

The one line of the implementation uses the theButton parameter (the UIButton touched) to grab the title of the button and set the label to the title.

I hope this didn’t scare you too much. The purpose of this exercise was to show that responsive and flexible interfaces can be accomplished in code without it being too much of a hassle. The biggest challenge is determining how the controls will be laid out and then coming up with the CGRectMake functions to define their locations.

Later in the book (Hour 23), we’ll look at tools for developing Universal Applications that can completely adapt to different devices and orientations. The foundation for using these advanced tools, however, is a solid understanding of Auto Layout and how user interfaces are built and displayed. It’s a good idea to practice the techniques discussed in this hour because they will form the basis for everything you build.

By implementing rotation and size-aware applications, you give your users the ability to use their devices in the way that feels most comfortable to them.

A. Although there is no problem implementing the upside-down portrait orientation using the approaches described in this hour, it isn’t recommended. When the iPhone is upside-down, the Home button and sensors are not in the “normal” location. If a call comes in or the user needs to interact with the phone’s controls, the user will need to rotate the phone 180 degrees—a somewhat complicated action to perform with one hand.

Q. How do I get the controls in application XYZ to behave using Auto Layout?

A. This is a difficult question with no clear answer because there may be dozens of ways of implementing constraints that have the desired effect. I have implemented Auto Layout constraints in all my sample projects. You may want to take a look at those to get an idea of how I solved resizing problems. (Landscape, however, is up to you!)

a. Update Frame

b. Remove Frame

c. Clear Frames

d. Remove Constraints

2. Which method is executed after an interface rotation has taken place?

a. didRotateFromInterfaceOrientation

b. didMoveFromInterfaceOrientation

c. didSwitchFromInterfaceOrientation

d. changedInterfaceOrientation

3. How many different orientations may be returned by the didRotateFromInterfaceOrientation method?

a. 1

b. 2

c. 3

d. 4

4. Apple’s system for creating interfaces that adapt to different-sized displays is called what?

a. Auto Layout

b. Springs and Struts

c. Flow System

d. Smart Grid

5. You can define a proportional relationship between object sizes using which constraint property?

a. Value

b. Constant

c. Multiplier

d. Priority

6. The space from the front of one object to the edge of another is called what?

a. Trailing space

b. Front space

c. Preface space

d. Leading space

7. If you use a constraint to set the width of an object to a specific value, you are doing what to the object?

a. Setting

b. Pinning

c. Forcing

d. Dimensioning

8. To determine the point in the middle of a screen (X,Y), what logic should you use?

a. screen width/2, screen height/2

b. screen width*2, screen height*2

c. screen width-screen height, screen height-screen width

d. screen width-screen height, screen height-screen width

9. To programmatically set an action for a button, you can use which of the following methods?

a. addButton:action:forControlEvents

b. addSelector:forControlEvents

c. addAction:forControlEvents

d. addTarget:action:forControlEvents

2. A. Immediately after an interface rotation has taken place, the method didRotateFromInterfaceOrientation is called.

3. D. A total of four orientations are available: Landscape Left, Landscape Right, Portrait, and Portrait Upside-Down.

4. A. The Auto Layout system is used in OS X and iOS to enable developers to create responsive interface designs.

5. C. The Multiplier setting for a constraint can be used to create a proportional relationship between interface elements.

6. D. The leading space is the amount of space from the edge of one object to the front of another.

7. B. The act of setting a dimension or distance constraint is known as pinning.

8. A. Divide the screen’s width and height by 2 to locate a point in the exact center of the screen.

9. D. Use the addTarget:action:forControlEvents to programmatically configure the actions for a button.

2. Return to an earlier lesson and revise the interface to support multiple different orientations and screen sizes. Use any of the techniques described in this hour’s exercises for the implementation.