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 variable 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.swift file, 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 can use a segue to transition to further scenes. Development within the content area of the scenes is the same as developing in any other view.

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 “drill-down” hierarchy that navigation controllers are known for.

What’s important to realize here is that you can keep doing this. You can add additional 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 other 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 variable 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 variables via parentViewController in any of the other views.

The Health application on the iPhone, for example, presents different ways of viewing your health information by 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 value 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.swift file. 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 variable property (a String) 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 shows 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 “next” 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 File.

2. Choose the iOS Source category and Cocoa Touch 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), make sure that iPhone (or iPad) is selected, and set the language to Swift.

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 GenericViewController. 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.

Next, we need to make sure that Xcode knows this is the initial view controller to display when the application starts. Make sure that the navigation controller is still selected in the document outline, and then open the Attributes Inspector (Option-Command-4), and check the Is Initial View Controller check box within the View Controller section.

Finally, use the Size drop-down within the Simulated Metrics section to set a simulated size, as we’ve done previously. This isn’t required, of course, but it gives us a consistent interface to target for the lesson.

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 also have a single variable 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 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 Next 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 Show, as shown in Figure 13.13. A new segue line (Show Segue 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.

Repeat this process, creating a show 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 dragging a navigation item into the scene (just drop it anywhere on the view, it doesn’t matter). Next, select the navigation item within document outline. Use the Attributes Inspector (Option-Command-4) and 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.swift file should be visible, because we’re defining variable 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 variable 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. (You can drag from the circle beside the countLabel definition in GenericViewController.swift to the label within the scene—essentially the reverse of what you just did—and accomplish the same thing.)

Repeat this for the third scene, connecting its push count label to the same variable property.

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

var pushCount: Int = 0

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.

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 that it is displayed on the screen when a new scene is pushed into view.

We need to cast the parentViewController to our custom class of CountingNavigationController, 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 func incrementCount(sender: AnyObject) {
    (parentViewController as! CountingNavigationController).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 (a standard view controller method that we’ll need to add). 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.swift file.

LISTING 13.2 Updating the Display in viewWillAppear:animated

Click here to view code image

---

1: override func viewWillAppear(animated: Bool) {
2:     super.viewWillAppear(animated)
3:     let displayCount=(parentViewController as! CountingNavigationController).pushCount
4:     countLabel.text=String(displayCount)
5: }

---

Line 3 declares a new constant, displayCount, and sets it to the pushCount variable property of the parent view controller. Line 4 uses the String() function to convert this value (an integer) to a string, and sets the countLabel’s text variable property to the 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 Assets.xcassets asset catalog in the project navigator so that it 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 File.

2. Choose the iOS Source category and Cocoa Touch class, and then click Next.

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

4. Set the language to Swift, 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 GenericViewController. 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.

Like the last project, we must make sure Xcode knows this is the view controller to display when the application starts. With the tab bar controller still selected in the document outline, open the Attributes Inspector (Option-Command-4) and check the Is Initial View Controller check box. Finally, use the Size drop-down within the Simulated Metrics section to set a simulated size of your choosing.

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 variable properties. The first, outputLabel, references a UILabel that contains the current values of the counters for all three scenes. The second variable 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 action methods: incrementCountFirst, incrementCountSecond, and incrementCountThird. A button in each scene invokes the method specific to that scene. Two additional 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 Item) 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 here. 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 1 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 2 and use the Two image file, and the third Scene 3 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 variable property. Add another new outlet 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 in GenericViewController.swift. Do the same for the second scene’s tab bar item, targeting barItem.

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 incrementCountFirst action. Name this new action incrementCountSecond. Repeat this for the third scene, connecting to a new action named incrementCountThird.

We start by establishing the three variable 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.

Click here to view code image

var firstCount: Int = 0
var secondCount: Int = 0
var thirdCount: Int = 0

To complete the implementation, we’ll create 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.swift file and add the updateCounts method, as shown in Listing 13.3.

LISTING 13.3 Updating the Display Using the Counter Values

Click here to view code image

---

 1: func updateCounts() {
 2:     let first=(parentViewController as!
 3:         CountingTabBarController).firstCount
 4:     let second=(parentViewController as!
 5:         CountingTabBarController).secondCount
 6:     let third=(parentViewController as!
 7:         CountingTabBarController).thirdCount
 8:     self.outputLabel.text =
 9:         "First: (first) Second: (second) Third: (third)"
10: }

---

Lines 2–7 set three constants (first, second, third) to the three variable properties in the parent view controller. Lines 8-9 set the outputLabel to a nicely formatted string using Swift’s string interpolation along with the first, second, and third constants.

Because we have added a uniform barItem variable property accessible from 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.

Add the code in Listing 13.4 to GenericViewController.swift.

LISTING 13.4 Updating the Tab Bar Item’s Badge

Click here to view code image

---

 1: func updateBadge() {
 2:     var badgeCount: Int
 3:     if (barItem.badgeValue != nil) {
 4:         badgeCount = Int(barItem.badgeValue!)!
 5:         badgeCount++
 6:         barItem.badgeValue=String(badgeCount)
 7:     } else {
 8:         barItem.badgeValue="1"
 9:     }
10: }

---

Line 2 declares a new integer variable, badgeCount, that will ultimately hold the number that will be displayed in the tab bar item’s badge.

Line 3 checks to see if the barItem’s badgeValue is nil (entirely empty). If it is, that means that updateBadge hasn’t be called before, and the badge should be set to 1 (line 8).

If the badgeValue is anything other than nil, lines 4–6 are executed. Line 4 sets the badgeCount to Int(barItem.badgeValue!)!. Kinda weird looking, don’t you think? Ignore the !’s, and it’s a bit easier to understand: We get the badgeValue of barItem, and then use Int() to return it as an integer. The !’s are necessary because badgeValue is an optional variable property and Int()’s return value is optional—meaning that if it can’t create an integer, it returns nil.

In Line 5, badgeCount is incremented by 1.

Finally, line 6 sets the barItem.badgeValue to the badgeCount (converted to a string).

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

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

Click here to view code image

---

@IBAction func incrementCountFirst(sender: AnyObject) {
    (parentViewController as! CountingTabBarController).firstCount++
    updateBadge()
    updateCounts()
}

---

Add similar code for each of the other methods: incrementCountSecond and incrementCountThird. The only difference will be the variable 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 variable 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 variable 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. Navigation controllers are required for pushing and popping views, and you can’t 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 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.

a. Display

b. Shove

c. Push

d. Show

2. Adding additional scenes to a tab bar control involves establishing a new what?

a. Relationship

b. Push

c. Modal dialog

d. Link

3. A tab bar icon has what dimensions?

a. 30×30 points

b. 30×30 pixels

c. 60×60 points

d. 90×90 points

4. To set the badge displayed on a tab bar item, you’ll access which variable property?

a. badge

b. badgeText

c. badgeValue

d. badgeCircle

5. To reference the tab bar view controller or the navigation view controller from one of the child controllers, what variable property do you use?

a. parent

b. parentViewController

c. superViewController

d. viewControllerTop

6. The recommended approach for starting a tab bar application uses which template?

a. Tab Bar Application

b. Single View Application

c. Master Detail Application

d. Empty Application

7. What is used to set the badge value of a tab bar item?

a. Integer

b. Float

c. String

d. Any object

8. When you connect additional scenes to a navigation controller, what will they inherit?

a. Navigation title

b. Navigation bar

c. Navigation icon

d. Navigation button

9. How many additional classes were used to manage the content of the scenes (not including the controller) in this hour’s exercises?

a. 1

b. 2

c. 3

d. None

10. Although Xcode automatically adds some new objects to your navigation scenes, you must add which of the following?

a. UINavigationButton

b. UINavigationBar

c. UINavigationItem

d. UINavigationList

2. A. New scenes are added to a tab bar controller by establishing relationships between new view controllers and the tab bar controller.

3. A. Tab bar icons should be roughly 30×30 points.

4. C. You’ll update the badgeValue variable property to change the badge displayed on a tab bar item.

5. B. Use the parentViewController variable property to grab the navigation or tab bar controller from any of the child controllers.

6. B. I always recommend using the Single View Controller as the starting point for tab bar applications, despite a separate tab bar template being available.

7. C. A String is used to set a tab bar item’s badge value.

8. B. New scenes added to a navigation controller will automatically inherit the navigation bar.

9. A. A single generic view controller class was used to handle all the additional scenes in both projects.

10. C. The UINavigationItem is no longer added automatically to scenes connected to a navigation controller.

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