CHAPTER 11: iPad Considerations

387

storyboards, this eliminates a lot of code, which is usually a good thing. If you’re the kind of person who likes to see all such configuration done in code, you’re free to do so, but for this example, we’re going to stick with what Xcode has provided.

The Code Defines the Functionality

One of the main reasons for keeping the view controller interconnections in a storyboard is that they don’t clutter up your source code with configuration information that doesn’t need to be there. What’s left is just the code that defines the actual functionality.

Let’s look at what we have as a starting point. Xcode defined several classes for us when the project was created, and we’re going to peek into each of them before we start making any changes.

The App Delegate

First up is BIDAppDelegate.h, which looks something like this:

#import <UIKit/UIKit.h>

@interface BIDAppDelegate : UIResponder <UIApplicationDelegate>

@property (strong, nonatomic) UIWindow *window;

@end

This is pretty similar to several other application delegates you’ve seen in this book so far.

Switch over to the implementation in BIDAppDelegate.m, which looks something like the following (we’ve deleted most comments and empty methods here for the sake of brevity):

#import "BIDAppDelegate.h"

@implementation BIDAppDelegate

@synthesize window = _window;

- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions { // Override point for customization after application launch. UISplitViewController *splitViewController =

(UISplitViewController *)self.window.rootViewController; UINavigationController *navigationController =

[splitViewController.viewControllers lastObject]; splitViewController.delegate = (id)navigationController.topViewController; return YES;

}

@end

www.it-ebooks.info

388	CHAPTER 11: iPad Considerations

This bunch of code really does just one thing: sets the UISplitViewController’s delegate property, pointing it at the controller for the main part of the display (the view labeled Detail in Figure 11–5). Later in this chapter, when we dig into split views, we’ll explore the logic behind that UISplitViewController delegate connection. But why make this connection here in code, instead of having it hooked up directly in the storyboard? After all, elimination of boring code—“connect this thing to that thing”—is really one of the main benefits of both nibs and storyboards. And you’ve seen us hook up delegates in nib files plenty of times, so why can’t we do that here?

To understand why using a storyboard to make the connections can’t really work here, you need to consider how a storyboard differs from a nib. A nib file is really a frozen object graph. When you load a nib into a running application, the objects it contains all “thaw out” and spring into existence, including all interconnections specified in the nib file. A storyboard, however, is something more than that.

Imagine each scene in a storyboard corresponding to a nib file. When you add in the metadata describing how the scenes are connected via segues, you end up with a storyboard. Unlike a single nib, a complex storyboard is not normally loaded all at once. Instead, any activity that causes a new scene to come into focus will end up loading that particular scene’s frozen object graph from the storyboard. This means that the objects you see when looking at a storyboard won’t necessarily all exist at the same time.

Since Interface Builder has no way of knowing which scenes will coexist, it actually forbids you from making any outlet or target/action connections from an object in one scene to an object in another scene. In fact, the only connections it allows you to make from one scene to another are segues.

But don’t just take our word for it, try it out yourself! First, select the Split View Controller in the storyboard (you’ll find it within the dock in the Split View Controller Scene). Now, bring up the connections inspector, and try to drag out a connection from the delegate outlet to another view controller or object. You can drag all over the layout view and the list view, and you won’t find any spot that highlights (which would indicate it was ready to accept a drag). In fact, the only item that you’ll see accepting your drag is the First Responder proxy contained within the same scene as the Split View Controller (and that’s not what we want in this case).

So, we’ll need to connect the delegate outlet from our UISplitViewController to its destination in code. Referring back to BIDAppDelegate.m, that sequence starts off like this:

UISplitViewController *splitViewController = (UISplitViewController *)self.window.rootViewController;

This lets us grab the window’s rootViewController, which you may recall is pointed out in the storyboard by the free-floating arrow directed at our UISplitViewController instance. Then comes this:

UINavigationController *navigationController = [splitViewController.viewControllers lastObject];

www.it-ebooks.info

CHAPTER 11: iPad Considerations

389

On this line, we dig into the UISplitViewController’s viewControllers array. We happen to know that it always has exactly two view controllers: one for the left side and one for the right (more on that later). So, we grab the one for the right side, which will contain our detail view. Finally, we see this:

splitViewController.delegate = (id)navigationController.topViewController;

This last line simply assigns the detail view controller to the delegate.

All in all, this extra bit of code is a small price to pay, considering how much other code is eliminated by our use of storyboards.

The Master View Controller

Now, let’s take a look at BIDMasterViewController, which controls the setup of the table view containing the app’s navigation. BIDMasterViewController.h looks like this:

#import <UIKit/UIKit.h>

@class BIDDetailViewController;

@interface BIDMasterViewController : UITableViewController

@property (strong, nonatomic) BIDDetailViewController *detailViewController;

@end

And its corresponding BIDMasterViewController.m file looks like this (after removing the noncode bits and methods that do nothing but call their superclass’s implementation):

#import "BIDMasterViewController.h"

#import "BIDDetailViewController.h"

@implementation BIDMasterViewController

@synthesize detailViewController = _detailViewController;

-(void)awakeFromNib

{

self.clearsSelectionOnViewWillAppear = NO; self.contentSizeForViewInPopover = CGSizeMake(320.0, 600.0); [super awakeFromNib];

}

.

.

.

-(void)viewDidLoad

{

[super viewDidLoad];

// Do any additional setup after loading the view, typically from a nib. self.detailViewController = (BIDDetailViewController

*)[[self.splitViewController.viewControllers lastObject] topViewController]; [self.tableView selectRowAtIndexPath:[NSIndexPath indexPathForRow:0 inSection:0]

animated:NO scrollPosition:UITableViewScrollPositionMiddle];

}

www.it-ebooks.info

390CHAPTER 11: iPad Considerations

.

.

.

-(BOOL)shouldAutorotateToInterfaceOrientation:

(UIInterfaceOrientation)interfaceOrientation

{

//Return YES for supported orientations

return YES;

}

.

.

.

@end

A fair amount of configuration is happening here, but fortunately, Xcode provides it as part of the split view template. This code contains a few things that are relevant to the iPad that you may not have come across before.

First, the awakeFromNib method starts off with this:

self.clearsSelectionOnViewWillAppear = NO;

The clearsSelectionOnViewWillAppear property is defined in the

UITableViewController class (our superclass), and lets us tweak the controller’s behavior a bit. By default, UITableViewController is set up to deselect all rows each time it’s displayed. That may be OK in an iPhone app, where each table view is usually displayed on its own, but in an iPad app featuring a split view, you probably don’t want that selection to disappear. To revisit an earlier example, consider the Mail app. The user selects a message on the left side, and expects that selection to remain there, even if the message list disappears (due to rotating the iPad or closing the popover containing the list). This line fixes that.

The awakeFromNib method also includes a line that sets the view’s contentSizeForViewInPopover property. Chances are you can guess what this does: it sets the size of the view if this view controller should happen to be used to provide the display for a popover controller. This rectangle must be at least 320 pixels wide, but apart from that, you can set the size pretty much however you like. We’ll talk more about popover issues later in this chapter.

The next point of interest here is the viewDidLoad method. In previous chapters, when you implemented a table view controller that responds to a user row selection, you typically responded to the user selecting a row by creating a new view controller and pushing it onto the navigation controller’s stack. In this app, however, the view controller we want to show is already in place from the start, and it will be reused each time the user makes a selection on the left. It’s the instance of BIDDetailViewController contained in the storyboard file. Here, we’re grabbing that BIDDetailViewController instance, anticipating that we’ll want to use it later, when we have some content to display.

The final thing worth mentioning is the shouldAutorotateToInterfaceOrientation: method. Typically, in an iPhone app, you would use this method to specify whether a particular orientation was suitable for your purposes. In an iPad app, however, the

www.it-ebooks.info