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?
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.)
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...
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.
Related
I am developing an iOS app that I have already developed for Android.
The problem is I don't know how to organize my UIViewControllers considering the following scheme of my app pages:
The scheme is simple: there is a login page which leads to the main page. From this main page, there are four buttons which all lead to a specific view hierarchy but at the very bottom of each, the user will be able to go back directly to the main page. Each page accessed by the main page will also have a custom back button (an image of my own)
The question is: is there any benefit in using a UINavigationController (obviously with the main page as its root) in my case? Or can I simply create each Controller and using only Modal Segues?
If your view controllers have a navigation relationship so using UINavigationController is the way to go:
In 'push' segue, you are basically pushing your ViewController into an
already setup "navigation stack". Well, of course, this is under the
assumption that the ViewController that performs the 'pushing'
operation belongs to the same navigation stack as the ViewController
is pushed into. Generally, you push a ViewController if the pushed
ViewController has some sort of a relationship with the pushing
ViewController. This is very common in applications that has a
NavigationController in its system. A good example for a push segue is
a system where you are displaying a list of contacts. And on tap of a
particular contact, you are pushing a VC that has the corresponding
details of the contact.
Example is real world: list of products => product details => product reviews
If you want to temporary present a view controller and the main focus is your view controller but you need to present another view controller to perform a task like "filter" , "login", adjust "settings" then modal segue is the way to go
In 'modal' segue, there is no stack as such. You are presenting a VC
'modally' over the presentee VC, if that makes sense. This can happen
across any ViewController without any relationship rules. The
presenter should take care of dismissing the VC it presented. A good
example for modal segue is login. On tap of login, you are modally
presenting a VC that has no relationship with the presenter.
If your view controllers are not related to each other, but each view controller has his own navigation stack then UITabBarController is the way to go
Storyboards (Xcode): What is the difference between a push and modal segue?
I would say if each of the additional view controllers from the main "home" view controller don't have any children view controllers, then you can just have each button present a view controller modally.
The main difference is if you are using a navigation controller, you can "pushing" a vc onto the navigation stack of view controllers, whereas presenting it modally can be thought of a "one time" action where the user does something on the new screen and has no where to advance to logically (like adding information to a new contact).
You can see this post for a more detailed answer:
What is the difference between Modal and Push segue in Storyboards?
Deciding whether to use a Modal segue vs a Show (push) depends entirely on purpose and context of the user's experience. If you are leading the user down a path which is linear, where each successive VC is diving deeper in to a singular idea, then use Show segues and NavigationControllers. Examples include, Settings app, where you can drill into all the specifics. Most e-commerce app will use a NavigationController to lead the user through a purchase.
If you want to present the user with a single concept, which the user can respond to, or close it to continue using the rest of the app. Then use a modal presentation. Adding a contact in the iPhone is a fine example of this.
Visually, the difference is that a Show segue presents the VC from the right side of the app, sliding onto the previous VC. (If the user has Arabic language turned on, a right to left language, the Show segue will come from the left hand side of the VC) A modal comes from the bottom of the app.
From looking at your drawing, but not know anything else about your app, I think you want to use NavigationControllers. You may also want to consider a TabBarController. If each of these buttons lead the user on various ways of using the app, like mini apps within one big one, then a TabBarController is appropriate.
I am trying to create an on-top structure where user can go to a general page G from any other pages with a special gesture and go back to the page where s/he comes from.
Is there a way to do this while not implementing a segue and an unwind segue from every other page to page G?
Thank you!
Yes, you can do this without having a segue from each controller, but it depends on how your controller hierarchy is set up. If for instance, you have a navigation controller, and all your view controllers are pushed onto its stack, you can create one segue from the navigation controller to the one you want to go to from any of your other view controllers. You could also do this if your other controllers are embedded in a tab bar controller (the tab bar controller would present the common controller).
Difference between navigation controller and viewcontroller?
I mean how can we decide when to use navigation controller or a normal view controller?
Just my two cents:
A UIViewController represents a single view and you can put buttons in this view controller to segue to another UIViewController. If you want to segue back to the first UIViewController, you will have to worry about putting a button in the second view controller that leads back to the first. If you are drilling down into view controllers, this can be tedious having to remember to give the user a way back to a previous view controller.
A UINavigationController does a lot of this tedious work for you. As mentioned, it contains a stack of UIViewControllers. It will create a navigation bar at the top that will allow you to easily go back up the hierarchy of view controllers.
In short, if you have a hierarchy of view controllers that you want the user to easily navigate around, inbed your UIViewControllers into a UINavigation controller.
UINavigation Controller is a combination of 2 or more view controllers,those are connected through "segue" feature of "Ios". Benefit of using Navigation Controller is that we can navigate between different screens easily with default "Back" button on each screen . We don't need to give any individual button to move back onto previous screen.
Whereas a ViewController provides a single screen & we can connect more screen using "segue" but we also have to design a "Back" button to navigate onto previous screen.
We should use Navigation Controller , in case where one option resides into another one.Like in an iPhone settings ->Mobile Data Options->Voice->4G or 3G or 2G. It's a hierarchy of menus so here navigation Controller is better option than using UIController.
We should use UiController with "segue " , in case where
we have to choose one option among multiple.Like -
Photos ->There are many folders in which , any one is selected, that are Favourites or People or Places .
Here's a very brief, high-level overview.
Whereas a UIViewController can be thought of as representing a single 'screen', UINavigationController, as the name implies, is used as a means of being able to navigate multiple 'screens'.
From the documentation:
The UINavigationController class implements a specialized view controller that manages the navigation of hierarchical content. This navigation interface makes it possible to present your data efficiently and makes it easier for the user to navigate that content. You generally use this class as-is but in iOS 6 and later you may subclass to customize the class behavior.
Please see the rest of the UINavigationController documentation here: https://developer.apple.com/library/ios/documentation/UIKit/Reference/UINavigationController_Class/index.html
Okay, Thank you everyone for helping me to find out a clear answer on this.
Navigation Controller consists of navigation bar and tool bar to move in and out from view controllers present in navigation stack.Therefore there can be many view controllers in Navigation Controller.
In view controller we don't have this facility and it represents a single screen view.
Please correct me If I am wrong.
See the Navigation Controller discussion in the View Controller Catalog.
Bottom line, a navigation controller actually is a view controller, but it just happens to be one that presents and navigates between other view controllers.
Let's say, I have a scene (pushed view controller with a navigation bar), which displays some tabular data in a table view.
In the navigation bar of that scene I have a + sign, which should open a new scene, where the user can add a new item (row to a core data table).
In the table view, each row has an arrow on the right side of each cell, which opens a scene where the user can edit that particular item's details.
Should I use a push or modal segue for the +?
Should I use a push or modal segue for the arrow?
What is the "best practise"?
I understand the difference between push and modal segues, but I want to know which is better suited for the above use cases.
If you want to follow Apple's best practices, I would suggest the following :
For the "Add" functionality, use a modal segue.
For example look at the contacts app. Pressing + shows a modal view controller.
What's the logic ? for start, modal view controllers usually have a "cancel" button, as opposed to the "back" button on a pushed vc.
When the user presses "back" - he'd expect a way to come back to the vc. Usually "back" saves your data on iOS (auto-saved).
So by using a modal segue you force the user to submit the form , or cancel. The modal presentation hints that you really need to fill this screen.
For editing - push. but modal could work as well (and you could reuse the same VC).
Reasons for push :
you get a hierarchy of vc's , going back and forward while drilling down.
(you should implement) auto saving when going back (just like other iOS apps)
For adding a new entity to the core data table, on tapping the + button (I assume its a right bar bar button item on the navigation bar), use the modal segue.
The view for adding a new row for the enity has to be presented modally and once the save is completed, dismiss the modal view and reload the table view to display the newly added item.
Also for displaying the details of an entity row, use the push segue. A user expects a push action when he selects a table cell and it is the ideal way to do that.
I hope this quick summary will help you :
When you want to show a detail view of a summary view, use a navigation controller and Push Segues. If the "parent" view doesn't really relate as far as data is concerned to the "child" view, then use a modal. A good example for a modal view would be any entry view. This view doesn't really have any relationship as far as data is concerned to the "parent" view., the entry screen will just take data dat from user & will save & can go away & giving control back to parent
I'm developing an iOS app just now with a Tab Bar navigation.
I have two screens which show the same information but in different formats (say, list and grid).
The two screens are different enough that they require separate controllers.
Users can toggle between the two views from a shared control bar button (toggle) at the top.
Scenario:
User presses the 'Places' button for the first time and it shows the places as a list.
They press 'grid' to see the same places displayed as a grid.
The user presses another tab bar button to navigate to a different screen.
When they press the "Places" button again, the app remembers their last viewed screen for places was the grid so the grid view is shown.
The user may then toggle back to list view. etc...
Can anybody recommend the best approach to achieving this?
One approach is to use one view controller that manages both views. That way, you don't have to bother with synchronizing data or subverting the normal function of UITabBarController -- there's just one controller. Also, don't try to overload the meaning of the tab for that controller. Instead, add a button to both views that tells the controller to switch to the other view. That'll be easier for your to build, and (more importantly) easier for the user to understand. It's not nice to make familiar controls do unfamiliar tricks.
If your view controllers are such that combining them into one would be complicated, then you can use two controllers and simply swap them in and out of the tab bar by modifying the tab bar controller's viewControllers array. You can still avoid having to sync data between them by having both controllers refer to the same data model.
I was trying to achieve this same thing, and it can actually be done with a basic setup of a TabBarController, NavigationControllers, ViewControllers, push segues, and unwinds.
TabBarController
|==> NavigationController --> PlacesController(grid view) --(push segue from nav bar)--> PlacesController(list view)
|==> NavigationController --> OtherController
|...
Make sure to have an unwind segue back from the list view controller to the grid view controller.
If you toggle between views then go to another tab (e.g. otherController) and come back, you'll return to the last view you were seeing because that's what is at the top of the stack of the NavigationController.