What You Should Know about iPad Navigation to Develop Your iOS App
Although the iPhone and iPad are very similar, one area in which they differ is in how a user can navigate through an iOS application. For example, in iPhone apps that use a master-detail architecture, a Back button is prominently displayed in a detail view to go back to the Master view.
An iPad app that uses Split view functionality for the master-detail architecture will not need that Back button. But there are many other user interface designs on the iPad where a Back button is often used.
Apple has built this ability into the iOS architecture and has made it an integral part of the view controller architecture, as personified in the Navigation controller.
A Navigation controller is a Container view controller that enables the user to navigate back and forth between view controllers. A Navigation controller is an instance of the UINavigationController class, which is a class you use “as is” and don’t subclass. The methods of this class provide support for managing a stack-based collection of custom view controllers.
This stack represents the path taken by the user through the application, with the bottom of the stack reflecting the starting point and the top of the stack reflecting the user’s current position in the application.
Apple’s UIKit framework (one of the Cocoa Touch frameworks) generally uses class names that begin with UI, such as UIView, UIViewController, UIImageView, UIButton, and many more. To avoid confusion, you should not use the UI prefix for your own class names. Apple also has special prefixes for many other frameworks.
For example, the Core Image framework includes classes such as CIColor, CIContext, CIFaceFeature, and so on. These naming conventions provide hints so that when you come across an Apple class named CIImage, you can expect to find it in the Core Image framework.
Some developers adopt their own special prefixes for all their custom classes, including simple schemes such as using the RT prefix, so that class names could be RTMasterViewController, RTMapController , RTWeatherController, and so on. It’s not necessary to use a unique prefix for every custom class name, but you should avoid using Apple’s class names for your own classes.
A stack is a commonly used data structure that works on the principle of “last in, first out.” Imagine an ideal boarding scenario for an airplane: Passengers would start being seated in the last seat in the last row, and they’d board the plane in back-to-front order until they got to the first seat in the first row, which would contain the seat for the last person to board.
When the plane reached its destination, everyone would deplane in the reverse order. That last person on — the person in row one, seat one — would be the first person off.
A computer stack works on the same concept. Adding an object is called a push. Removing an object is called a pop — touching the Back button pops the view controller for the view being displayed. When you pop an object off the stack, it’s always the last one you pushed onto it. The controller that was there before the push is still there and now becomes the active one.
Although the Navigation controller’s primary job is to act as a manager of other view controllers, it also manages a few views. Specifically, it manages a Navigation bar that displays information about the user’s current location in the data hierarchy, a Back button for navigating to previous screens, and any custom controls the current view controller needs.
When the user taps Events in the iPhone version, the Navigation controller pushes the next view controller onto the stack. The new view controller’s view slides into place and the Navigation bar items are updated appropriately. When the user taps the Back button on the Navigation bar, the current view controller pops off the stack, that view slides off screen, and the user finds himself back in the previous view.
The Navigation controller maintains the stack of view controllers, one for each of the views displayed. The very first view controller that the Navigation controller pushes onto its stack when a Navigation controller is created is called the Root view controller. It remains active until the user selects the next view to look at.
Navigation bars enable a user to navigate the hierarchy. Here’s what you need to know in order to make that work:
The view beneath the Navigation bar presents the current level of the application.
A Navigation bar includes a title for the current view.
If the current view is lower in the hierarchy than the top level, a Back button appears on the left side of the bar; the user can tap it to return to the previous level.
A Navigation bar may also have an Edit button on the right side — used to enter Editing mode for the current view — or even custom buttons.
On the iPad, the Master-Detail Application template has not one, but two Navigation controllers already included in the storyboard — one for the Master View controller and the other for the Detail View controller.
The only “problem” right now is that each Navigation controller has only one view controller to manage, which means you won’t be able to select anything and see a new view, with its accompanying Back button.
When you tap the first cell in the Master View controller (you’ll add the Test Drive label shortly), a new view controller will slide its view into place. If you select the Back button, you will slide back to the previous Detail view.
You have other (even slicker) iPad navigation options at your disposal, where you get a chance to change from navigation that uses the Navigation controller to something a bit more appropriate. For now, though, you’ll go with the Navigation controller approach, just to get you off and running.