Points, Pixels, and the Retina Display

You might be wondering why we’re talking about “points” instead of pixels. Earlier versions of this book did, in fact, refer to screen sizes in pixels rather than points. The reason for this change is Apple’s introduction of the retina display.

The retina display is Apple’s marketing term for the high-resolution screen on the iPhone 4, iPhone 4s, iPhone 5, and later-generation iPod touches, as well as the Retina iPad. It doubles the iPhone screen resolution from the original 320 × 480 pixels to 640 × 960 pixels (now up to 640 × 1136 on iPhone 5), and the iPad screen resolution from 1024 × 768 to 2048 × 1536.

Fortunately, you don’t need to do a thing in most situations to account for this. When we work with on-screen elements, we specify dimensions and distances in points, not in pixels. For older iPhones, iPad 1 , iPad 2, and iPad Mini 1, points and pixels are equivalent. One point is one pixel. On more recent model iPhones and iPod touches, however, a point equates to a 4-pixel square (2 pixels wide and 2 pixels high) and the screen is still 320 points wide, even though it’s actually 640 pixels across. Likewise, the latest iPads still have a screen geometry of 1024 × 768 points, although they actually have 2048 × 1536 pixels. Think of it as a “virtual resolution,” with iOS automatically mapping points to the physical pixels of your screen. We’ll talk more about this in Chapter 16.

In typical applications, most of the work in actually moving the pixels around the screen is managed by iOS. Your application’s main job in all this is making sure everything fits nicely and looks proper in the resized window.

Autorotation Approaches

Your application can take three general approaches when managing rotation. Which one you use depends on the complexity of your interface. We’ll look at all three approaches in this chapter.

With simpler interfaces, you can specify the correct constraints for all of the objects that make up your interface. Constraints tell the iOS device how your controls should behave when their enclosing view is resized. If you’ve worked with Cocoa on OS X, you may already be familiar with the basic process because it is the same one used to specify how Cocoa controls behave when the user resizes the window in which they are contained. This system is also known as Cocoa Autolayout, but we’ll be describing things in terms of constraints, which are the parts of Cocoa Autolayout that we can most directly interact with and configure.

The simplest way of using constraints is to configure them in Interface Builder (IB). Interface Builder lets you define constraints that describe how your GUI components will be repositioned and resized as their parent view changes or as other views move around. You did a little bit of this in Chapter 4 and will delve further into this subject in this chapter. You can think of constraints as equations that make statements about view geometry and the iOS view system itself as a “solver” that will rearrange things as necessary to make those statements true.

Constraints were added to iOS 6, but have been present on the Mac for a bit longer than that. On both iOS and OS X, constraints can be used in place of the old “springs and struts” system that came before. Constraints can do everything the old technology could do, and a whole lot more.

Configuring constraints in Interface Builder is quick and easy, but this approach isn’t appropriate for all applications. More complex interfaces must handle autorotation in a different manner. For more complex views, you will need to override methods from UIViewController in your view’s controller class. This will enable you to lay out your views the way you want. We’ll show you this approach at the end of this chapter.

Let’s get started, shall we? Before we get into the different ways you can configure your GUI to shuffle its views around, we’ll show you how to specify which orientations your app will allow.

Supported Orientations at the App Level

First, we need to specify which orientations our application supports. When your new Xcode project window appeared, it should have opened to your project settings. If not, click the top line in the project navigator (the one named after your project), and then make sure you’re on the General tab. Among the options available in the summary, you should see a section called Deployment Info and, within that, a section called Device Orientation (see Figure 5-2) with a list of checkboxes.

This is how you identify which orientations your application supports. It doesn’t necessarily mean that every view in your application will use all of the selected orientations; but if you’re going to support an orientation in any of your application’s views, that orientation must be selected here.

Have you noticed that the Upside Down orientation is off by default? That’s because, if the phone rings while it is being held upside down, the phone is likely to remain upside down when you answer it. iPad app projects default to all four orientations being supported because the iPad is meant to be used in any orientation. Since our project is an iPhone project, we can leave the checkboxes the way they are.

Now, select Main.storyboard, find a Label in the object library, and drag it into your view, dropping it somewhere just above the center, as shown in Figure 5-3. Select the label’s text and change it to This way up. Changing the text may shift the label’s position, so drag it to make it horizontally centered again.

Now, press R to build and run this simple app. When it comes up in the simulator, try rotating the device a few times by pressing -Left-Arrow or -Right-Arrow. You’ll see that the entire view (including the label you added) rotates to every orientation except upside-down, just as we configured it to do.

We’ve identified the orientations our app will support, but that’s not all we need to do. We can also specify a set of accepted orientations for each view controller, giving us some more fine-grained control over which orientations will work in different parts of our apps.

Per-Controller Rotation Support

Let’s configure our view controller to allow a different, smaller set of accepted orientations. Note that the global configuration for the app specifies a sort of absolute upper limit for allowed orientations. If the global configuration doesn’t include upside-down orientation, for example, there’s no way that any individual view controller can force the system to rotate the display to upside-down. All we can do in the view controller is place further limits on what is acceptable.

Single-click BIDViewController.m. Here we’re going to implement a method, defined in the UIViewController superclass, that lets us specify which orientations we’ll accept.

- (NSUInteger)supportedInterfaceOrientations {
    return (UIInterfaceOrientationMaskPortrait |
            UIInterfaceOrientationMaskLandscapeLeft);
}

This method lets us return a C-style mask of acceptable orientations. This is iOS’s way of asking a view controller if it’s okay to rotate to a specific orientation. In this case, we’re returning a value that indicates that we’ll accept two orientations: the default portrait orientation and the orientation you get when you turn your phone 90º clockwise, so that the phone’s left edge is at the top. We use the Boolean OR operator (the vertical bar symbol) to combine these two orientation masks and return the combined value.

UIApplication.h defines the following orientation masks, which you can combine in any way you like using the OR operator, as previously discussed:

• UIInterfaceOrientationMaskPortrait
• UIInterfaceOrientationMaskLandscapeLeft
• UIInterfaceOrientationMaskLandscapeRight
• UIInterfaceOrientationMaskPortraitUpsideDown

In addition, there are some predefined combinations of these for common use cases. These are functionally equivalent to OR’ing them together on your own, but can save you some typing and make your code more readable:

• UIInterfaceOrientationMaskLandscape
• UIInterfaceOrientationMaskAll
• UIInterfaceOrientationMaskAllButUpsideDown

When the iOS device is changed to a new orientation, the supportedInterfaceOrientations method is called on the active view controller. Depending on whether the return value includes the new orientation, the application determines whether it should rotate the view. Because every view controller subclass can implement this differently, it is possible for one application to support autorotation with some of its views but not with others, or for one view controller to support certain orientations under certain conditions.

Feel free to play around with this method by returning different orientation mask combinations. You can force the system to constrict your view’s display to whichever orientations make sense for your app, but don’t forget the global configuration we talked about earlier! Remember that if you haven’t enabled upside-down there (for example), none of your views will ever appear upside-down, no matter what their views say.

Overriding Default Constraints

Grab another label from the library and drag it over to the layout area. This time, instead of moving toward a corner, drag it toward the left edge of your view, lining up the label’s left edge with the left edges of the other labels on the left side, and centering it vertically in the view. Dashed lines will appear to help you out. Figure 5-7 shows you what this looks like.

After placing the left label, give it a title like “Left.” Press R to run your app in the simulator, rotate it to landscape mode, and you’ll see that the left label maintains its distance from the top (again, just like the upper-left label), placing it a fair bit below center. Oops!

We need to create a new constraint to make this work, so go back to Xcode and select the left label in your nib. Adding a constraint to force this label to stay vertically centered is really easy—just select Editor Align Vertical Center in Container. When you do this, Xcode creates a new constraint and immediately selects the new constraint itself in the editor view. This is slightly confusing, but don’t worry! Just click the label again to select it. Make sure the size inspector is on display by pressing 5, and you’ll see that this label now has a constraint aligning its center Y value to that of its superview. Press R to run the app again, do some rotating, and you’ll see that all the labels now move perfectly into their expected places. Nice!

Now, let’s complete our ring of labels by dragging out a new one to the right side of the view, lining up its right edge with the other labels on the right, and aligning it vertically with the Left label. Change this label’s title to Right, and then drag it a bit to make sure its right edge is vertically aligned with the right edges of the other two labels, using the dashed blue line as your guide. We want to use the automatic constraints that Xcode can provide us with, so select Editor Resolve Auto Layout Issues Add Missing Constraints to generate them.

With the label selected, take a peek at the constraints that Xcode has created for us. You should see two of them, one tying the label’s right edge to the right edge of the UR label above it, and another one aligning its baseline (i.e., the imaginary bottom line of the text in the label) to the Left label. Xcode actually made a perfect guess! Build and run again, do some rotating again, and you’ll see that all the labels stay on the screen and are correctly positioned relative to each other (see Figure 5-8). If you rotate back, they should return to their original positions. This technique will work for a great many applications.

That’s all fine, but we can do a lot more with just a few clicks! Let’s say that we’ve been struck by a great visionary idea and decide that we want the two uppermost labels, UL and UR, to form a sort of header, filling the entire width of the screen. With a bit of resizing and some constraints, we’ll sort that out in no time.

Full-Width Labels

We’re going to create some constraints that make sure that our labels stay the same width as each other, with tight spacing to keep them stretched across the top of the view even when the device rotates. Figure 5-9 shows what we’re shooting for.

The hardest part about this is being able to visually verify that we’ve got the result we want, where each label is precisely centered within its half of the screen. In order to make it easier to see whether we’ve got it right, let’s temporarily set a background color for the labels. Select both the UL and UR labels, open the attributes inspector, and scroll down to the View section. Use the Background control to select a nice, bright color. You’ll see that the entire frame of each label fills with the color you chose.

Now, direct your attention to the UL label and drag the resizing control on its right edge, pulling it almost to the horizontal midpoint of the view. You don’t have to be exact here, for reasons that will become clear soon. After doing this, resize the UR label by dragging its left-edge resizing control to the left until you see the dashed blue guideline appear, which tells you that it’s the recommended width from the label to its left. Now we’ll add a constraint to make these labels fill the whole width of their superview. Select both the UL and UR labels, and select Editor Pin Horizontal Spacing from the menu. That constraint tells the layout system to hold these labels beside one another with the same horizontal space they have right now. Build and run to see what happens. Rotate the device, and you’ll probably see something like Figure 5-10.

That’s pretty close, but not really what we had in mind. So what’s missing? We’ve defined constraints that control each label’s position relative to its superview and the allowed distance between the two labels, but we haven’t said anything about the size of the labels. This leaves the layout system free to size them in whatever way it wants (which, as we’ve just seen, can be quite wrong). To remedy this, we need to add one more constraint.

Make sure the UL label is selected, then hold down the Shift key () and click the UR label. With both labels selected, you can make a constraint that affects both of them. From the menu, select Editor Pin Widths Equally to make the new constraint. You’ll now see a new constraint appear, and just like before, it’s automatically selected. Whenever a constraint is selected, the affected views are highlighted with a yellow color, so here you’ll see that both of the top labels have a yellow highlight, as shown in Figure 5-11. You may also note that if the two labels weren’t exactly the same width before you created this constraint, they certainly are now, as the existence of this new constraint snaps them into place.

If you run again at this point, you should now be able to rotate the device and see the labels spread across the entire screen (see Figure 5-9).

In this example, all of our labels are visible and correctly laid out in multiple orientations; however, there is a lot of unused space on the screen. Perhaps it would be better if we also set up the other two rows of labels to fill the width of the view or allowed the height of our labels to change so that there will be less empty space on the interface? Feel free to experiment with the constraints of these six labels and perhaps even add some others. Apart from what we’ve covered so far, you’ll find more actions that create constraints in the Editor Pin menu. And if you end up making a constraint that doesn’t do what you want, you can delete it by selecting it and pressing the Backspace key, or try configuring it in the attributes inspector. Play around until you feel comfortable with the basics of how constraints work. We’ll use them now and then throughout the book; but if you want the full details, just search for “auto layout” in Xcode’s documentation window.

In the course of your experimentation, you’re bound to notice that sometimes no combination of constraints will give you exactly what you want. In some cases, you’ll need to rearrange your interface more drastically than can be handled with this technique. For those situations, a little more code is in order. Let’s take a look at that next.

Creating and Connecting Outlets

Make sure Main.storyboard is still selected and bring up the assistant editor (as you did in the previous chapter). Make sure you can see BIDViewController.m next to the GUI layout area, and then control-drag from each of the four buttons to the class extension in your code (the section between the first @interface and @end lines near the top of the file) to create four outlets called actionButton1, actionButton2, actionButton3, and actionButton4. Now do the same for the large view, naming this outlet contentView.

Once you’ve connected all five buttons to new outlets, the upper part of BIDViewController.m should look like this:

#import "BIDViewController.h"
 
@interface BIDViewController ()
@property (weak, nonatomic) IBOutlet UIButton *actionButton1;
@property (weak, nonatomic) IBOutlet UIButton *actionButton2;
@property (weak, nonatomic) IBOutlet UIButton *actionButton3;
@property (weak, nonatomic) IBOutlet UIButton *actionButton4;
@property (weak, nonatomic) IBOutlet UIView *contentView;
 
@end

Moving the Views on Rotation

To move these views around and make the best use of space, we need to override the method willAnimateRotationToInterfaceOrientation:duration: in BIDViewController.m. This method is called automatically after the device has been rotated into a new orientation, but before the final rotation animations have occurred.

Add the following method at the bottom of BIDViewController.m, just above the @end:

- (void)willAnimateRotationToInterfaceOrientation:(UIInterfaceOrientation)
             toInterfaceOrientation duration:(NSTimeInterval)duration {
   [self doLayoutForOrientation:toInterfaceOrientation];
}

As you can see, this method just passes the new orientation along to another method, one which you haven’t written yet. We put this functionality into a new method for reasons that will become clear soon. Here’s the new method:

- (void)doLayoutForOrientation:(UIInterfaceOrientation)orientation {
    if (UIInterfaceOrientationIsPortrait(orientation)) {
        [self layoutPortrait];
    } else {
        [self layoutLandscape];
    }
}

The doLayoutForOrientation: method simply passes control off to one of two other methods, which individually set up the views in the correct positions. We haven’t defined those yet either, so here they are, along with some constant values we’re going to use for some of our layout geometry:

static const CGFloat buttonHeight = 40;
static const CGFloat buttonWidth = 120;
static const CGFloat spacing = 20;
 
- (void)layoutPortrait {
    CGRect b = self.view.bounds;
     
    CGFloat contentWidth = CGRectGetWidth(b) - (2 * spacing);
    CGFloat contentHeight = CGRectGetHeight(b) - (4 * spacing) -
                            (2 * buttonHeight);
     
    self.contentView.frame = CGRectMake(spacing, spacing,
                                        contentWidth, contentHeight);
     
    CGFloat buttonRow1y = contentHeight + (2 * spacing);
    CGFloat buttonRow2y = buttonRow1y + buttonHeight +  spacing;
     
    CGFloat buttonCol1x = spacing;
    CGFloat buttonCol2x = CGRectGetWidth(b) - buttonWidth - spacing;
     
    self.actionButton1.frame = CGRectMake(buttonCol1x, buttonRow1y,
                                          buttonWidth, buttonHeight);
     
    self.actionButton2.frame = CGRectMake(buttonCol2x, buttonRow1y,
                                          buttonWidth, buttonHeight);
     
    self.actionButton3.frame = CGRectMake(buttonCol1x, buttonRow2y,
                                          buttonWidth, buttonHeight);
     
    self.actionButton4.frame = CGRectMake(buttonCol2x, buttonRow2y,
                                          buttonWidth, buttonHeight);
}
 
- (void)layoutLandscape {
    CGRect b = self.view.bounds;
     
    CGFloat contentWidth = CGRectGetWidth(b) - buttonWidth - (3 * spacing);
    CGFloat contentHeight = CGRectGetHeight(b) - (2 * spacing);
     
    self.contentView.frame = CGRectMake(spacing, spacing,
                                        contentWidth, contentHeight);
     
    CGFloat buttonX = CGRectGetWidth(b) - buttonWidth - spacing;
    CGFloat buttonRow1y = spacing;
    CGFloat buttonRow4y = CGRectGetHeight(b) - buttonHeight - spacing;
    CGFloat buttonRow2y = buttonRow1y + floor((buttonRow4y - buttonRow1y)
                                              * 0.333);
    CGFloat buttonRow3y = buttonRow1y + floor((buttonRow4y - buttonRow1y)
                                              * 0.667);
     
    self.actionButton1.frame = CGRectMake(buttonX, buttonRow1y,
                                          buttonWidth, buttonHeight);
     
    self.actionButton2.frame = CGRectMake(buttonX, buttonRow2y,
                                          buttonWidth, buttonHeight);
     
    self.actionButton3.frame = CGRectMake(buttonX, buttonRow3y,
                                          buttonWidth, buttonHeight);
     
    self.actionButton4.frame = CGRectMake(buttonX, buttonRow4y,
                                          buttonWidth, buttonHeight);
}

Each of those methods functions in a similar way, but they achieve different results. They first store the superview’s bounds rectangle in a local variable for the sake of convenience. Next, they use that rectangle’s size and our geometry constants to figure out a good position for the big content view, and then set that view’s frame so that it ends up in the right spot. After that, some button positions are calculated, and each button’s frame is adjusted so that they all end up in the right places, too.

That’s the 10,000-foot view, but there are lots of interesting details here. The size and position of all views, including controls such as buttons, are specified in properties called frame and bounds, both of which are structs of type CGRect. The difference between the two is this. A view’s frame describes its location within its parent view’s coordinate system, while a view’s bounds describe its own coordinate system, which is useful in case you want to figure out where subviews belong. There are many ways of using these values, but one of the most typical uses is the kind of thing we’re doing here: using the position of one or more objects to decide the position of another. As a rule, if you want to calculate a view’s position, you are likely to read a parent view’s bounds or a sibling view’s frame to base things on—you end up setting the target view’s frame to put it in its place. We’ll see more of this throughout the book.

Apart from that, the Apple-provided CGRectMake() function lets you easily create a CGRect by specifying the x and y positions along with the width and height. We also use the CGRectGetHeight() and CGRectGetWidth() functions here, which simply tell you the height and width, respectively, of a given CGRect.

There’s one more thing to do here before we’re done. Since we’ve gone to all the trouble of setting exact positions for all our GUI elements in code, we should use that code for all of our GUI layout, including the moment when the view objects have just been loaded from the storyboard or nib file. Add the bold lines shown here to the viewDidLoad method to make this happen:

- (void)viewDidLoad
{
    [super viewDidLoad];
    // Do any additional setup after loading the view, typically from a nib.
    UIApplication *app = [UIApplication sharedApplication];
    UIInterfaceOrientation currentOrientation = app.statusBarOrientation;
    [self doLayoutForOrientation:currentOrientation];
}

Here we’re grabbing the shared instance of the UIApplication class and asking it for its statusBarOrientation. This tells us in which direction the screen is oriented when the view loads. We pass that along to the doLayoutForOrientation: method that we wrote earlier, so that it will position all of our GUI elements properly.

Save this code. Now build and run the application to see it in action. Try rotating and watch how the buttons slide over to new positions, nicely lined up along the right side of the screen. Rotate back, and they go right back to where they started from. Smooth! You should also try running in different simulated devices. Xcode lets you choose whether you want to run as a 3.5-inch or 4-inch iPhone. Both should work equally well.