timeLabel.text = [NSDateFormatter localizedStringFromDate:now dateStyle:NSDateFormatterNoStyle timeStyle:NSDateFormatterLongStyle];

}

Here, we’re grabbing the current date, and then using a handy NSDateFormatter class method to pull out date and time values separately, passing each off to the appropriate label. And that’s all we need to do! Click the Run button, and you’ll see our dazzling new clock in fine working order (see Figure 10-8).

Figure 10-8. Our silliest clock in all its glory

As you’ve seen, for what we wanted to do here, using a table view with static cells can be a whole lot simpler than taking the dataSource-based approach, since our design lets us use a fixed set of cells. If you want to display a more open-ended dataset, you’ll need to use the dataSource methods, but static cells provide a much simpler way to create certain types of displays, such as menus and details.

You Say Segue, I Say Segue

It’s time to move on to another new piece of functionality that Apple built in to iOS 5: the segue. With segues, you can use Interface Builder to define how one scene will transition to another. This works only in storyboards, not nibs.

www.it-ebooks.info

The idea is that you can use a single storyboard to represent the majority of your app’s GUI, with all scenes and their interconnecting segues represented in the graphical layout view. This has a couple of nice side effects. One is that you can see and edit the entire flow of your application in one place, which makes working with the big picture a lot easier. Also, this ends up eliminating some code from your view controllers, as you’ll see soon.

NOTE: We’ve noticed some confusion about the word segue and its pronunciation. It’s an English word (borrowed from Italian) that means about the same as transition. It’s mostly used in certain

journalistic and musical contexts, and is relatively uncommon. It’s pronounced “seg-way,” just like the Segway transportation devices (whose name, it should now be clear, is basically a

trademarkable respelling of segue).

Segues are most useful in the context of a navigation-based application—the kind that you’re quite familiar with after the past few chapters. Here, we’re not going to build anything as large as the app we created in Chapter 9, but we’ll demonstrate how you could start down that road using a combination of segues and static tables.

Creating Segue Navigator

Use Xcode to create a new iOS application project, choosing the Empty Application template. Name the project Seg Nav. This creates the same empty app that you’ve seen in earlier chapters, including the non-storyboard code for creating a window in the app delegate. Since we’re going to create a storyboard and want it to autoload, as with our previous project, select BIDAppDelegate.m, find the application:didFinishLaunchingWithOptions: method, and delete all but the last line of the method.

- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions

{

self.window = [[UIWindow alloc] initWithFrame:[[UIScreen mainScreen] bounds]]; // Override point for customization after application launch. self.window.backgroundColor = [UIColor whiteColor];

[self.window makeKeyAndVisible]; return YES;

}

Select the Seg Nav folder in the project navigator, and choose File New New File…. to create a new file. From the User Interface section, choose Storyboard and click Next. Name the new file MainStoryboard.storyboard.

After the file is created, we need to configure our project so that the storyboard will be loaded when the app launches. Select the icon representing the Seg Nav project itself at the top of the project navigator. In the target’s Summary tab, you’ll find a popup button that lets you set the Main Storyboard. Set it to MainStoryboard by clicking the popup and picking MainStoryboard (which is, conveniently, the only item in the list).

www.it-ebooks.info

Filling the Blank Slate

Select MainStoryboard.storyboard in the project navigator. You’ll see the familiar layout area appear, but now it’s completely empty. Remedy that by finding a Navigation Controller in the object library and dragging it into the layout area to create our app’s initial scene.

As you may recall, the UINavigationController class doesn’t display any content itself. It shows just the navigation bar. So, when you drop the UINavigationController into your storyboard, Interface Builder does you a favor, creating a UIViewController and its view at the same time. You’ll see the two controllers side by side, with a special sort of arrow pointing from the navigation controller to the view controller. This arrow represents the navigation controller’s rootViewController property, and it is connected to the view controller so that you have something to load.

Now, you could start populating that view with some content, but in this case, it would be instructive to create a storyboard-based app that mimics some of the behavior of the Nav app we built in Chapter 9. So, let’s insert a table view controller into the mix as our start screen. To do that, select the view controller on the right (the one that’s being pointed to, as opposed to the navigation controller that is pointed from), and press the delete key to delete it. Then drag a Table View Controller from the object library to the layout area, placing it to the right of the navigation controller, just as the original one was.

At this point, the navigation controller doesn’t know where to find its rootViewController, so we need to reestablish that connection with the new view controller. Control-drag from the navigation controller to the table view controller, and you’ll see a popup that looks like the same popup you’e seen before when connecting outlets and actions (see Figure 10-9). This time, however, instead of showing you outlets or actions, it displays a group of connections labeled Storyboard Segues. This contains an item called Relationship - rootViewController, followed by three items labeled Push, Modal, and Custom. Those final three choices are used for creating segues between scenes, and we’ll get to them soon. For now, select the rootViewController entry to establish that relationship.

www.it-ebooks.info

Figure 10-9. This image shows the popup that appears as the result of control-dragging from the navigation controller to the new table view controller. We are selecting the item that establishes the table view controller as the root view controller.

Now, let’s make this table view show a menu of items. We want it to work about the same as the root table view in the Nav app from Chapter 9. However, with static table view cells, this is going to be a lot easier!

Use the dock to select the table view (as opposed to the table view controller), and use the attributes inspector to change its Content to Static Cells. You’ll see that the table view immediately acquires three cells. We’re going to use only two, so select one of the cells and delete it.

Select each of the two remaining table view cells, and use the inspector to change its Style to Basic so they acquire a title. Then change the titles to Single view and Submenu, respectively (see Figure 10-10).

www.it-ebooks.info

Figure 10-10. Our two static cells, with their titles changed

Now, we’ll provide some titling so that the table view plays nicely with the navigation controller. Select the navigation item (it looks like an empty toolbar) that is shown at the top of the table view. Use the attributes inspector to set its Title to Segue Navigator and its Back Button to Seg Nav. Note the Back Button setting doesn’t define a value that will be displayed while this view is shown; rather, it defines the value that a subsequent view controller will show in its back button, leading back to this root view.

Run the app to get a sense of how things are going so far. You should see the root table view that you just created, containing two cells with the titles you just specified.

That’s actually all we need to do for this root view, and we did it all in Interface Builder, without writing a single line of code! You may recall that in the Nav app in Chapter 9, we had a custom UITableViewController subclass that contained code to allocate and initialize every other view controller. Every time we added a new second-level controller, we needed to import its header and add code to create an instance of it. Thanks to storyboards, we don’t need any of that.

As we add each second-level controller to our storyboard, we’ll connect a root table view cell to it using a segue in Interface Builder. Our root controller class doesn’t need to know about any of the other controllers, since it’s not directly involved in creating or displaying them. That’s why we can get by with a plain UITableViewController here, instead of making a subclass of our own.

www.it-ebooks.info