When I should use Navigation Controller?

Question

I don't know when I should use Navigation Controller instead of use segue with normal View Controller? And if use segue, which different between Modal and Push segue?

Can you give me an example?

Solution 1

Short answer: Use a Navigation Controller with "show" segues only to implement DRILL DOWN behavior.

For example, Navigation Controller → Authors → Books → Book

• For each level below the "root" (Authors), the Navigation Controller automatically adds the title bar and back button. So on Books, the back button is automatically named "<Authors".

• The child View Controllers must be connected with SHOW segues -- show segues tell the Navigation Controller "this is a parent-child relationship" and cause the expected slide-in-from-the-right transition. (To jump outside the hierarchy, for example, Books → Login, use a modal segue instead.)

• The root View Controller has a navigation bar that you can add more bar buttons to, but child View Controllers don't, because it's added automatically.

FoodTracker Example

Now the odd-seeming layout of the FoodTracker tutorial in Apple's Start Developing iOS Apps (Swift) can be explained. **What's up with that second nested Navigation Controller? It's just a simple list of meals: tap a meal to show it in Meal Detail, or tap Add to and Meal Detail becomes Add Meal.

FoodTracker Storyboard

• The first Navigation Controller makes My Meals the root of the drill-down hierarchy for any number of views "pushed" from there on (no further Navigation Controllers are needed just to do that).

• But, Meal Detail is used for both displaying an existing meal and adding a new meal. To add a new meal, Cancel and Save buttons are needed. The second Navigation Controller allows those buttons to be added (see 3rd point above) by making Meal Detail a root.

• Displaying an existing meal is a push segue, but adding a meal is a modal segue (a new meal isn't a drill-down). This is important: the reason Add Meal can't just be pushed is that the automatic back button ("< My Meals") becomes ambiguous: does it save or cancel?

Because "navigation" and "push" are very general terms, and because it's nice to get a free back button, it's tempting to think Navigation Controllers are to go from anywhere to anywhere, but the behavior is intended just for hierarchical traversal.

(This is an old question but I was also confused about this as an iOS n00b and like the OP I still had questions.)

Solution 2

In my experience, there is no a general rule to decide this kind of things, it depends on the usability of your future App...

Navigation controller helps the user to remember where they are in every moment, and how they can go back, but could not be the best thing to use if you have too many levels... And more important, if you are using a NavigationController or a TabBarController, you have a class, accessible from all the other ViewControllers where you can have general functionality or data...

The difference between the modal and push segue is that in the first you will always return to the parent ViewController, because you are only showing new information on top, while in the push one you are replacing one ViewController with other...

Solution 3

You use navigation controllers when you want to enable back button functionality. You still use 'normal' view controllers, you just embed them in a navigation controller. Then, you can push view controllers and be able to go back.

Comments

[Proton]

What different between "Navigation Controller -> UITableView Controller -> UITableView Controller" and "Navigation Controller -> UITableView Controller -> Navigation Controller -> UITableView Controller"

[Guy Chen]

There's no reason to wrap your view controllers in a navigation controller twice.

[Proton]

I wanted to display a table (ex authors), when tap a row it transited to a new table (ex books). So what differ, when I designed by storyboard, I embed "Navigation Controller -> UITableView Controller -> UITableView Controller" and the other I embed "Navigation Controller -> UITableView Controller -> Navigation Controller -> UITableView Controller"

[Proton]

Can u give an example or demo project ? Thank u !

[apascual]

For example, imagine that you have a typical project with authentication and that should keep a connection open, then, could be a good idea to store that connection as a property in the NavigationController better than passing it through the different UIViewControllers that would be appearing...

[Proton]

Can you explain deeply more ?

[Proton]

I wanted to display a table (ex authors), when tap a row it transited to a new table (ex books). And use storyboard ! How I do that ?

[apascual]

You should stick to the "Model - View - Controller" paradigm... For example: in the first UITableViewController, when a row is selected you should implement "didSelectRow" and perform the segue programmatically setting the author for the new UITableViewController in "prepareForSegue". Then, when the author is received in the new UITableViewController, you should get the list of books and update your tableView...

[apascual]

That scheme is pretty common, what I am suggesting is that you store in the NavigationController the instance you would use to get the list of authors or books, and in every Controller that would be displayed you would have access to that instance instead of passing it though the Controllers...

[KMC]

Personally, I like your answer more than the accepted one. With concrete examples, it's very easy to understand.

[TonyM]

This has been very helpful indeed. It makes a lot of things around navigation controllers more lucid - many thanks!

[J2N]

Very helpful! I was under the impression Nav controllers were to be used everywhere. This saves me a lot of grief.