Hour 13. Advanced Storyboards Using Navigation and Tab Bar Controllers

,

Over the past few hours, you’ve become familiar with creating multiscene applications using modal scene segues and popovers. These are useful and common user interface (UI) features, but many iOS applications take a more “structured” approach to scene layout. Two of the most popular application layout methods involve the use of navigation controllers and tab bar controllers. Navigation controllers enable a user to drill down from one screen to another, exposing more detail as they go. You’ll see this everywhere in iOS—from the settings app to bookmarks in Safari. The second approach, implementing a tab bar controller, is used for developing apps with multiple functional features, where each tab presents a different scene where the user can interact with a new set of controls.

In this hour, you learn about these two controllers and how they can provide a whole new world of interface options for your applications.

Previously relying on quite a bit of coding prowess, these advanced view controllers required multiple chapters just to cover basic implementation, and far more code than could be reasonably covered in a 24 Hours book. Now, it’s literally a matter of drag and drop.

Before we get started with looking at these new features, let’s take a moment to review where we are in the book, and, specifically, what we’ve learned over the past few hours.

We also started (in the past two hours) building apps with multiple scenes. This includes creating new view controller subclasses to handle each scene, adding segues, and, if necessary, writing code to manually trigger a segue. The key to being successful in creating multiscene applications is being able to easily exchange information between the different scenes so you can build a cohesive user experience. The more scenes you have, the more planning you need upfront to make sure that everything works the way you want it to.

In the preceding hour’s lesson, you created a delegate attribute on one custom view controller subclass and used it to refer to the initial view controller object. Another approach is to create a brand-new class that does nothing but manage the information that needs to be shared across scenes. The two types of view controllers that we use in this hour include a “parent” view controller that manages multiple scenes that are presented to the user. This parent controller provides an excellent opportunity for creating public properties to facilitate exchanging information between scenes—since it is present regardless of which scene is visible. We put this to the test in our sample projects a bit later.

This hour is mostly visual—giving your typing fingers a break before kicking back in in the next hour. The Xcode storyboard feature makes what we’re about to do possible in a 24 Hours book and enables you to concentrate on coding application logic instead of worrying about getting the right scenes to display when you need them.

Managing this transition between scenes is the navigation controller. It creates a “stack” of view controllers. The root view controller is at the bottom. As a user navigates deeper into the scenes, each successive view controller is pushed on the stack, with the current scene’s view controller at the very top. To return to a previous level, the navigation controller pops the topmost controller off the stack and returns to the one below it.

By default, the navigation item for a scene contains a title for that scene and a Back button. The Back button is added as a bar button item (UIBarButtonItem) within the navigation item (yes, just like the bar buttons you used in the last hour). You can even drag additional bar button items into the navigation item to add your own custom buttons to the navigation bar that is displayed for that scene.

I fully expect that if you’ve made it through that description you’re getting a bit worried about having to manually handle all those different objects (and that’s why doing this in code is not trivial!). Don’t fear: Interface Builder makes it painless, and once you see how each scene is constructed, you’ll have no problem working with all of these objects in your apps.

First, you want to establish the code files for one or more view controller subclasses to handle the user’s interactions within a given navigation controller scene. This is the same as any other scene. If you don’t recall how to add new subclasses to your project, review Hours 11 and 12 to see how the modal scenes tutorials work.

Open your storyboard file in the IB editor. If you want your entire application to fall under the navigation controller, select the view controller in the default view and delete it. (You want to remove the corresponding ViewController.m and .h files, as well.) This removes the default scene. Next, you drag an instance of the navigation controller object from the Object Library into the document outline or the editor. This adds what appears to be two scenes to your project, as shown in Figure 13.2.

The scene labeled Navigation Controller Scene represents the navigation controller. It is just a placeholder for the object that is going to control all the scenes that fall underneath it. Although you won’t want to change much about the controller, you can use the Attributes Inspector to customize its appearance slightly (choosing a color scheme/tint, if desired).

The navigation controller is connected via a “relationship” to a scene titled with Root View Controller. By default, IB sets a table view controller as the root view controller. This can be removed, and the relationship to any custom view controller you’d like, created. We’ll be doing that in one of today’s tutorials.

The scenes under a navigation controller are exactly like any other scene; they just happen to have the navigation bar at the top and are able to use a push segue to transition to another scene. Development within these scenes is the same as developing in any other scene.

You can change three attributes:

Title: The title string that is shown at the top of the view

Prompt: A line of text that provides instruction to the user (if needed) and is shown above the title

Back Button: The text that appears in the Back button of the next scene

Now wait a minute. You can edit the text of the button that appears in a scene you don’t even have yet? Yes. By default, when you transition from one navigation controller scene to another, the “title” of the previous scene shows up as the title of the Back button in the next scene. Sometimes, however, the title may be long, or not necessarily appropriate. In these cases, you can set the Back button attribute to whatever string you want, and if the user drills down to the next scene, that text will be displayed in the button that takes you back to the scene.

The Back button text does one additional thing. Because iOS can no longer use its default behavior to create a Back button, it creates a new custom bar button item within the navigation item that contains the title you wanted. You can customize this bar button item even more, changing its color and appearance using the Attributes Inspector.

So far, there is only a single scene under the navigation controller, so the Back button would never be displayed. Let’s see how you can chain together multiple scenes to create the “drilldown” hierarchy that navigation controllers are known for.

What’s even more important to realize here is that you can keep doing this. You can add additional push segues and even branch from multiple segues to follow different paths, as shown in Figure 13.4. Xcode keeps track of everything for you.

Keep in mind that these are just views, like any other, so you are welcome to add modal segues or popovers in your storyboard as well. One advantage that this hour’s controllers have over modal segues is that transitioning to and from views is handled automatically. You don’t need to add any code to use the Back button or the swipe gesture within a navigation controller hierarchy, nor (as you learn shortly) any code to switch between scenes in a tab bar controller application.

We can (and will) create a subclass of UINavigationController that does nothing but include public properties we want to share between scenes, assign that as the identity class of the navigation controller that is managing all of our scenes, and then access those properties via parentViewController in any of the other views.

The Phone application on the iPhone, for example, presents different ways of viewing your calls and contacts using a tab bar controller, as shown in Figure 13.5.

Like a navigation controller, the tab bar controller handles everything for you. When you touch a button to transition between scenes, it just works. You don’t need to worry about programmatically handling tab bar events or manually switching between view controllers. The similarity doesn’t end there.

The scenes presented by a tab bar controller must contain a tab bar item (UITabBarItem) that has a title, an image, and, if desired, a badge (a little red circle with a number in it).

To add a tab bar controller to an application, I recommend again starting with a Single View Application template. If you don’t want the initial scene to segue into the tab bar controller, you just delete the initial scene by removing its view controller and then delete the corresponding ViewController interface and implementation files. Once your storyboard is in the state you want, drag an instance of the tab bar controller object from the Object Library into the document outline or the editor. This adds a controller and two sample tab bar scenes to the view, as shown in Figure 13.6.

The tab bar controller scene represents the UITabBarController object that coordinates all the scene transitions. Within it is a tab bar object that can be customized slightly with IB, changing the color.

From the tab bar controller are two “relationship” connections to the two scenes that the tab bar will display. The scenes can be differentiated by the name of the tab bar button that is added to them (Item 1 and Item 2, by default).

Using the Tab Bar Item section, you can set a value to be displayed in the tab bar item badge. Typically, you want to set this via tab bar item’s badgeValue property (an NSString) in code. You can also use the Identifier pop-up menu to choose from over a dozen predefined tab bar icons and labels. If you choose to use a predefined icon/label, you cannot customize it further, because Apple wants these to remain constant throughout iOS.

To set your own image and title, use the Bar Item settings. The Title field sets the label for the tab bar item, and the Image drop-down associates an image resource from your project for the item.

That’s everything you need to configure a scene for a tab bar controller. But what if you want to add additional scenes to the tab bar? We tackle that now, and, as you’ll see, it’s even easier than adding a scene to a navigation controller.

Drag a new view controller instance into the document outline or editor. Next, Control-drag from the tab bar controller to the new scene’s view controller in document outline. When prompted, choose Relationship Segue, View Controllers, as shown in Figure 13.8.

Creating the relationship does everything we need; it automatically adds a tab bar item to the new scene, ready to be configured. We can keep doing this to create as many tabs and scenes as we need in the tab bar.

Now that you’ve seen how to add these new view controllers to your project, let’s actually create a few examples that demonstrate these principles in action. As promised, these will be light on the typing, so don’t expect a masterpiece. The beauty is that once you know see how easy it is to use these controllers, the possibilities for your applications will open up tremendously.

Figure 13.9 demonstrates what we want to accomplish.

We remove the default table view controller that is used with the navigation controller and add three scenes, designating one as the root view scene for the controller. A Push button is included in each scene’s view with an action method to increment a counter—as well as a segue from that button to the next scene.

Next, click the Main.storyboard file and then select the View Controller line in the document outline area (Editor, Show Document Outline) and again press Delete. The scene will disappear. We now have the perfect starting point for our app.

To add these two additional classes, follow these steps:

1. Click the + button at the bottom-left corner of the project navigator and choose New File.

2. Choose the iOS Cocoa Touch category and Objective-C class, and then click Next.

3. Name the new class CountingNavigationController, set the subclass to UINavigationController (you will have to type in the class name), and if you’re building for iPad, click Targeted for iPad.

4. Click Next.

5. On the last setup screen, make sure that Xcode has chosen the code folder for your project (navigate to it, if not), choose your main project code group from the Group pop-up menu, and then click Create.

Repeat this process to create a new UIViewController subclass named GenericView Controller. Make sure that you choose the right subclass for each of the new classes; otherwise, you’ll have difficulty later on.

We want to associate this controller with our CountingNavigationController class, so select the Navigation Controller line in the document outline, and then open the Identity Inspector (Option-Command-3). From the class drop-down menu in the Custom Class section, choose CountingNavigationController. Ta da! Done.

Now let’s add the additional scenes we need and associate them with the generic view controller class we created.

Control-drag from the navigation controller to the new view controller. When finished dragging, release your mouse button. You are prompted for the type of connection to make. Choose Relationship Segue, Root View Controller. Your storyboard should now look like Figure 13.11.

You’re ready to add the other two scenes to the storyboard. Drag two more instances of the view controller object from the Object Library into the editor or the document outline. In a few minutes, these will be connected to the root view controller scene to form a series of scenes that are managed by the navigation controller.

After adding the additional scenes, we want to do two things to each of them (including the root view controller scene). First, we need to set the identity of each scene’s view controller. Next, it’s a good idea to set a label for each view controller so that the scene has a friendlier name.

Start by selecting the view controller connected to the Counting Navigation Controller (the root view controller) and opening the Identity Inspector (Option-Command-3). Within the Custom Class section, use the Class drop-down menu to pick the GenericViewController. Still within the Identity Inspector, set the Label field (within the Document section) to First. Move to one of the new scenes you added, select its view controller line, set its class to GenericViewController, and the label to Second. Repeat the process for the last scene as well, setting its custom class and a label of Third. When finished, your document outline should look like Figure 13.12.

The GenericViewController class will have a single private property called countLabel that references a label in the UI displaying the current count of pushes. It will also have a private action method named incrementCount that increases the pushCount property in the CountingNavigationController by one.

To build a segue for the navigation controller, we need something to trigger it. Within the storyboard editor, add a button (UIButton) labeled Push to the first and second scenes, but not the third. Why not the third? Because it is the last scene that can be displayed; there’s nothing after it to segue to.

Next, Control-drag from the button in the first scene to the second scene’s view controller line in the document outline, or target the scene directly in the editor. When prompted for the segue type, choose Push, as shown in Figure 13.13. A new segue line (push Segue from Push to Second) will be added to the first scene in the document outline, and the second scene will inherit the navigation controller’s navigation bar, as well as gain a navigation item in its view.

Repeat this process, creating a push segue from the second scene’s button to the third scene. Your IB editor should now contain a fully realized navigation controller sequence. Click and drag each scene in the view to arrange it in a way that makes sense to you. Figure 13.14 shows my interconnected views.

Begin by going through each of the scenes (first, second, and third) and selecting the navigation item within document outline. Open the Attributes Inspector (Option-Command-4) and use the Title field to set each view’s title. Title the first view (the root view controller) 1st Scene, the second 2nd Scene, and the third... wait for it... 3rd Scene.

In each scene, add a label (UILabel) near the top that reads Push Count: and a second label (the output label) with the default text of 0 (and a large, center aligned font, if you like) to the center of each view.

For my design, I’m setting slightly different backgrounds for each of the three scenes. This can help users identify when they have moved to a different part of the application, but it has no functional bearing on the project. Figure 13.15 shows my final interface design.

Position your display in the IB editor so that the first scene is visible (or just use the document outline), and click its push count label, and then switch to the assistant editor mode. The GenericViewController.m file should be visible, because we’re defining private properties and methods.

That created the outlet and the connection from the first scene; now you need to connect it to the other two scenes. Control-drag from the second scene’s push count label and target the countLabel property you just created. The entire line will highlight, as shown in Figure 13.16, showing you are making a connection to an existing outlet. Repeat this for the third scene, connecting its push count label to the same property.

Switch to the second view controller and Control-drag from its button to the existing incrementCount action. You’ve just made all the connections we need.

Click here to view code image

@property (nonatomic) int pushCount;

That’s all we need to do to implement the custom CountingNavigationController class. Because it is a subclass of a UINavigationController, it already performs all the navigation controller tasks we need, and now it stores a pushCount value.

To access the pushCount property from the GenericViewController class that is handling the content for all the scenes in the application, we need to import the custom navigation controller’s interface file in GenericViewController.h. Add this line following the existing #import statement:

Click here to view code image

#import "CountingNavigationController.h"

We’re all set to finish our implementation, which is just a matter of adding logic to GenericViewController that increments the counter and makes sure it is displayed on the screen when a new scene is pushed into view.

We need to typecast the parentViewController to our custom class of Counting NavigationController, but the full implementation is just a single line. Implement incrementCount, as shown in Listing 13.1.

LISTING 13.1 Implementing the incrementCount Method

Click here to view code image

---

- (IBAction)incrementCount:(id)sender {
    ((CountingNavigationController *)self.parentViewController).pushCount++;
}

---

The final step is to update the display to show the current count. Because pushing the button increments the push count and pushes a new scene into view, the incrementCount action isn’t necessarily the best place for this logic to fall. In fact, it won’t always be accurate, because the count could be updated in another view, and then the Back button used to “pop” back to the original view, which would now be showing an invalid count.

To get around this, we just add the display logic to the viewWillAppear:animated method. This method is called right before a view is displayed onscreen (regardless of whether it is through a segue or by a user touching the Back button), so it is a perfect place to update the label. Add the code in Listing 13.2 to the GenericViewController.m file.

LISTING 13.2 Updating the Display in viewWillAppear:animated

Click here to view code image

---

1: -(void)viewWillAppear:(BOOL)animated {
2:     [super viewWillAppear:animated];
3:     NSString *pushText;
4:     pushText=[NSString stringWithFormat:@"%d",
5:          ((CountingNavigationController *)self.parentViewController).pushCount];
6:     self.countLabel.text=pushText;
7: }

---

Line 3 declares a new string, pushText, that will contain a string representation of the counter. Lines 4–5 initialize this string using the NSString stringWithFormat method. The "%d" format string is replaced by the contents of the pushCount property, accessed using the same approach as in the incrementCount method.

In the last step, line 6, the countLabel is updated with the pushText string.

Figure 13.17 shows the result we want.

Each scene will again have a single button that calls a method to increment that scene’s counter. Because the project calls for a unique counter for each scene, each button invokes a slightly different action method. This enables us to share all the code that is in common between the views (updating the badge and the count label) but have a slightly different increment action to target the right counter for that scene.

That’s it; no segues needed this time around.

Click the Images.xcassets asset catalog in the project navigator so that displays in the editor. Drag the Images folder from the OS X Finder into the column on the left within the catalog. This action creates a new folder in the catalog and makes the images available to your project.

To create these two custom classes, follow these steps:

1. Click the + button at the bottom-left corner of the project navigator and choose New File.

2. Choose the iOS Cocoa Touch category and Objective-C class, and then click Next.

3. Name the new class CountingTabBarController and configure the subclass to UITabBarController.

4. If you’re building for iPad, click Targeted for iPad, and then click Next.

5. Be sure to create the class files inside your main project code group, or drag the files there later.

Repeat these steps, creating a new UIViewController subclass named GenericView Controller. We did almost exactly this for the previous example, so if you’re experiencing déjà vu, it’s okay.

Associate the tab bar controller with the custom CountingTabBarController by selecting the Tab Bar Controller line in the document outline, and then open the Identity Inspector (Option-Command-3). Within the Custom Class section, use the class drop-down menu to choose CountingTabBarController.

After adding the additional scene, use the Identity Inspector to set each scene’s custom class to be the GenericViewController and establish a label for easy identification.

Select the Item 1 scene that corresponds to the first tab in the tab bar. Using the Identity Inspector (Option-Command-3), set the Class drop-down menu to GenericViewController and the Label field to First. Move to the second scene and repeat, but set the label to Second. Finally, select the view controller line in the new scene you created. Set its class to GenericViewController and the label to Third. Note that the third scene isn’t yet connected to the tab bar controller; this is perfectly fine.

The GenericViewController class will have two private properties. The first, outputLabel, references a UILabel that contains the current values of the counters for all three scenes. The second private property, barItem, connects to each scene’s tab bar item so that we can update its badge value.

Because there are three separate counters, the GenericViewController class requires three private action methods: incrementCountFirst, incrementCountSecond, and incrementCountThird. A button in each scene invokes the method specific to that scene. Two additional private methods (updateCounts and updateBadge) will also be added so that we can easily update the current count and badge value without having to rewrite the same code in each increment method.

Control-drag from the Counting Tab Bar Controller line in the document outline to the view controller of the scene you added (labeled Third). When prompted for the segue type, choose Relationship Segue, View Controllers, as shown in Figure 13.18. A new segue line (Relationship from "view controllers" to Third) will be added to the counting tab bar controller scene. In addition, the tab bar will become visible in the third scene, and a tab bar item will appear in the third scene’s view.

Because all the other scenes are already connected to the tab bar controller, we’re done making the segue connections. Now we can move on to creating the interface.

Begin by adding a label (reading Scene One) to the first scene near the top of the view. Add a second label, to be used for output, to the center of the view. The output will span multiple lines, so use the Attributes Inspector (Option-Command-4) to set the number of lines for the label to 5. You can also center the text and adjust its size as desired.

Next, add a button labeled Count to the bottom center of the view. This will increment the counter for the view.

Now update the tab bar item to set its icon and label. Click the tab bar item at the bottom of the view, and open the Attributes Inspector. Use the Bar Item settings to set the title to Scene One and the image to One, as shown in Figure 13.19.

Repeat these design steps for the other two scenes. The second scene should be labeled Scene Two and use the Two image file, and the third Scene Three with Three.

As with the previous project, I’m setting a different background color for each of my views. This is purely optional, but can be used as a visual indicator that the user has moved to a different area of the application.

Figure 13.20 shows my completed tab bar application design.

outputLabel (UILabel): Used for displaying the results of each scene’s counter, this label must be connected in each scene.

barItem (UITabBarItem): References the tab bar item that was automatically added to each view by the tab bar controller. This connection must be made in each scene.

And the actions:

incrementCountFirst: Connected to the Count button in the first scene, this action method updates the first scene’s counter.

incrementCountSecond: Connected to the Count button in the second scene, this action method updates the second scene’s counter.

incrementCountThird: Connected to the Count button in the third scene, this action method updates the third scene’s counter.

Make sure that the first scene is visible in IB (or just use the document outline), and then switch to the assistant editor mode.

Next, Control-drag from the tab bar item in the first scene to below the outputLabel property. Add another new outlet for a private property named barItem.

After creating the outlets for the first scene, connect them to the other two scenes. Control-drag from the second scene’s output label and target the outputLabel property in GenericViewController.m. Do the same for the second scene’s tab bar item.

Repeat this for the third scene, connecting its label and tab bar item to the defined outlets.

Move to the second scene and Control-drag from its button to a line below the increment CountFirst action. Name this new private action incrementCountSecond. Repeat this for the third scene, connecting to a new private action named incrementCountThird.

We start by establishing the three public properties to track the Count button presses in each of three scenes. These are going to be added in the CountingTabBarController class and will be named firstCount, secondCount, and thirdCount. We’ll be adding these to the CountingTabBarController.h file because we want them to be publicly accessible to other classes.

Click here to view code image

@property (nonatomic) int firstCount;
@property (nonatomic) int secondCount;
@property (nonatomic) int thirdCount;

To access these properties from the GenericViewController class, import the custom tab bar controller’s interface file in GenericViewController.h. Add this line following the existing #import statement:

Click here to view code image

#import "CountingTabBarController.h"

To complete the implementation, we start by creating two methods to update the display within the scenes and then add the actions to increment the counters and call the update methods.

Edit the GenericViewController.m file and update the @interface block at the top to declare a private method prototype for updateCounts. This isn’t strictly necessary, but it is good practice and prevents warnings from Xcode. Update the @interface block in GenericViewController.m to read as follows:

Click here to view code image

@interface GenericViewController ()
@property (weak, nonatomic) IBOutlet UILabel *outputLabel;
@property (weak, nonatomic) IBOutlet UITabBarItem *barItem;

- (IBAction)incrementCountFirst:(id)sender;
- (IBAction)incrementCountSecond:(id)sender;
- (IBAction)incrementCountThird:(id)sender;
-(void)updateCounts;
@end

Now, add the updateCounts method to the GenericViewController.m file, as shown in Listing 13.3.

LISTING 13.3 Updating the Display Using the Counter Values

Click here to view code image

---

1: -(void)updateCounts {
2:     NSString *countString;
3:     countString=[NSString stringWithFormat:
4:                  @"First: %d Second: %d Third: %d",
5:             ((CountingTabBarController *)self.parentViewController).firstCount,
6:             ((CountingTabBarController *)self.parentViewController).secondCount,
7:             ((CountingTabBarController *)self.parentViewController).thirdCount];
8:     self.outputLabel.text=countString;
9: }

---

The code begins in line 2 by declaring a countString to hold the formatted version of the output string. Lines 3–7 create the string using the properties stored in the CountingTabBar Controller instance.

Line 8 outputs the formatted string in the outputLabel.

Because we have added a uniform barItem property to all the scenes, we only need a single method in the GenericViewController class to handle incrementing the badge value. We’ll call this method updateBadge. This is another private method, so before we write it, we should add a prototype to the @interface block at the top of GenericViewController.m. Update the existing block to read as follows:

Click here to view code image

@interface GenericViewController ()
@property (weak, nonatomic) IBOutlet UILabel *outputLabel;
@property (weak, nonatomic) IBOutlet UITabBarItem *barItem;

- (IBAction)incrementCountFirst:(id)sender;
- (IBAction)incrementCountSecond:(id)sender;
- (IBAction)incrementCountThird:(id)sender;
-(void)updateCounts;
-(void)updateBadge;
@end

Then add the code in Listing 13.4 to GenericViewController.m.

LISTING 13.4 Updating the Tab Bar Item’s Badge

Click here to view code image

---

1: -(void)updateBadge {
2:     NSString *badgeCount;
3:     int currentBadge;
4:     currentBadge=[self.barItem.badgeValue intValue];
5:     currentBadge++;
6:     badgeCount=[NSString stringWithFormat:@"%d", currentBadge];
7:     self.barItem.badgeValue=badgeCount;
8:     }

---

Line 2 declares a new string, badgeCount, that will ultimately hold a formatted string to be assigned to the badgeValue property.

Line 3 declares an integer, currentBadge, that will hold the current badge in integer form.

In Line 4, the NSString instance method intValue is used to store the tab bar item’s badgeValue, in integer form, in currentBadge.

Line 5 adds one to the current badge count.

Finally, line 6 initializes the badgeCount string with the value of currentBadge, and line 7 sets the tab bar item’s badgeValue property to the new string.

The purpose method must update the appropriate counter in the CountingTabBarController class and then call the updateCounts method and updateBadge method to update the interface appropriately. Listing 13.5 shows an implementation for the incrementCountFirst method.

LISTING 13.5 Adding a Method in GenericViewController.m to Update Each Scene’s Counter

Click here to view code image

---

- (IBAction)incrementCountFirst:(id)sender {
    ((CountingTabBarController *)self.parentViewController).firstCount++;
    [self updateBadge];
    [self updateCounts];
}

---

Add similar code for each of the other methods: incrementCountSecond and increment CountThird. The only difference will be the property you increment. Instead of firstCount, you use secondCount and thirdCount.

The tab bar items should also show and increment their badges when the Count button is used, providing yet another form of visual feedback that you can give to the user.

You should now be comfortable creating projects based around the tab bar and navigation controllers—a dramatic improvement over just a single scene, don’t you think? The next hour’s lesson finishes up our look at custom view controllers by introducing another interesting UI element and an entirely new application template. Get your fingers ready for more typing!

The navigation controller (UINavigationController) is often combined with other types of views, such as the table view, to enable the viewing of structured information in a logical manner. You learn a bit more about this in the next hour, but a read of the UINavigationController class reference is highly recommended. Unlike many class references, the navigation controller documentation fully describes how navigation controllers can and should be used. You’ll want to learn about the UINavigationController view hierarchy, as well as the UINavigationControllerDelegate protocol, which can help you respond to advanced user events within a navigation controller.

The tab bar controller (UITabBarController) also offers additional features beyond what we were able to cover here. If there are too many buttons to be displayed in a single tab bar, for example, the tab bar controller provides its own “more” view in the form of a navigation controller. This enables you to expand the user’s options beyond the buttons immediately visible onscreen. The UITabBarControllerDelegate protocol and the UITabBarDelegate can even implement optional methods to enable the user to customize the tab bar within the application. You can see this level of functionality within Apple’s Music application.

The second view controller, the tab bar controller, is used to create applications with a single unifying bar at the bottom that can be used to switch between different scenes. Each scene, according to Apple’s guidelines, should perform a unique function. Unlike the navigation controller, all the scenes managed by a tab bar controller are “random access,” meaning that users can switch between whatever tabs they like; there is no preset order.

Both of these controllers present an opportunity for sharing information between the different scenes that they manage by implementing properties and methods on a custom subclass of the controller.

Finally, and possibly the best thing you learned in this hour’s lesson, both of these controllers can be implemented almost entirely visually with the Xcode storyboard tools. This is a significant change from earlier releases where the code required to implement these features made them difficult to discuss.

A. The fact that the tab bar controller and navigation controller have a nice place to implement shared properties is great, but not necessary. You can always create a custom class in your application and reference it in other classes that need to exchange data.

Q. Can I mix and match scenes and segues?

A. Yes and no. You can’t use a push segue without a navigation controller or create a working tab bar application without a tab bar controller. You can, however, implement a navigation controller that is used in conjunction with a tab bar controller, display a modal segue that transitions to a navigation controller-managed series of scenes, and so forth.

Q. Are tab bar and toolbar objects interchangeable?

A. Absolutely not. A tab bar is for switching between different functional areas of an application. A toolbar is for activating a feature within a single functional area of an app.

2. Tab bar item images are the same as toolbar images. True or false?

3. Attaching an action to an object that is performing a segue will cause the segue to be ignored. True or false?

2. False. Tab bar images are “approximately” (Apple’s own words!) 30×30 points and are not defined by the alpha channel. They should be created as simple line drawings.

3. False. Both the action and the segue will be executed.

2. Update the navigation controller example so that the navigation branches depending on a user’s selection.