If you’re creating an iPhone/iPod Touch app with a lot of hierarchical data, you’ll be displaying that data in table views, i.e. lists. But how do you navigate among the tables holding the data? That’s where UINavigationController comes in.
In the MainWindow.nib, you add a Navigation Controller and point its Root View Controller to the main RootViewController, which populates the display based on the data held in its child controllers. In the AppDelegate there’s another UINavigationController which feeds the view to the MainWindow and this AppDelegate’s controller is managed by the RootViewController. So there’s a stack of controllers being used. The first screen you see is built by the RootViewController based on information it gets from its child controllers. When you select a row, the corresponding controller is pushed onto the main controller stack in AppDelegate and the view switches to the one defined by that controller:
AppDelegate’s view controller, which is the one that tells MainWindow what to display:
There’s a bubble up effect in the diagram above as when you select a row, RootController decides which view controller to use, pushes that onto AppDelegate’s view controller stack which in turn refreshes the MainWindow display.
The iPhone handles going back for you as it displays the name of the previous controller in the AppDelegate’s view controller stack. When you select that name, the OS pops the current view off the view controller stack and the previous one reappears.
Once a controller, picked by RootController, is active, all display events are handled by it until you choose the previous view from the button the iPhone gives you in the top left of the screen. That child view controller can have its own hierarchy of controllers to control navigation deep into its area of the data.
How the classes fit together and how they affect what you see on the screen is like this: