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.
Related
Is it possible to launch an app to a specific level of a navigation stack using a storyboard?
I'm looking to recreate the model employed by Mail.app, where the app launches into the Inbox, but this is actually one level down the navigation stack, and tapping the back button takes you to the root...
I understand how this can be done via code, i.e. instantiating the navigation controller within the app delegate and then manually pushing the view controller(s) to create the desired stack, but I'd really like to know if there's a way to achieve the same using storyboards.
Unfortunately I don't think there is because you need to instantiate your navigation controller at some point that will house your view controllers, and if you do this through storyboards the best you can do is set the navigation controller to be the entry point.
However, it is pretty straightforward to do from code. If your navigation controller has two view controllers where ViewControllerOne pushes to ViewControllerTwo, then you can just can just push to the second one without an animation as follows:
navigationController.pushViewController(secondViewController, animated: false)
And the user will be one level deep in the navigation controller.
I have a total of 3 views. A menu, the main view where the action happens, and a settings menu.
You can access the settings from both the menu and the main view and go back using the back button provided by the Navigation Controller.
In the main view I have hidden the NavigationBar to free some space, and there's a specific button to go back to the menu. From what I know and have read, I assume this just adds more and more views to the Navigation Stack if I keep going from the main view to the menu again and again, creating a lot of views in the stack.
I'd like someone to tell me whether my assumption is true or not, and evt. explain me the whole process behind navigating and views.
UINavigationController has a property viewControllers which is the stack of view controllers that have been pushed there.
If you use push segues in your storyboard each time you trigger this segues you push the current controller to the stack.
If you have a special logic I suggest you manage controllers programmatically.
This might clear it all.
There are basically following types of Segues to navigate to any viewController
Show (Push)
Show Detail (Replace)
Present Modally
Present as Popover
And to move back use Unwind Segue
You can read more regarding this here
i'm curious about what's the best way to plan the controllers for my app.
i want my main screen to have 3 button.
1) should open a nav controller with details view
2) should open a controller with other buttons that lead to others controllers
3) should open a tab bar with 2 pages ( or eventually use a switch to change page instead of the tab bar)
this is the schema of what i want
http://i59.tinypic.com/2rrvrd4.png
Is it a correct schema or i should use my controllers differently? will apple reject an apple with such schema?
thanks
As #Fogmeister pointed out in the comments, going for a UITabBarController as the main interface for your app actually seems to be a more appropriate solution here.
However, you can go with the interface that you described, but then you should keep in mind that with your current setup, you are not only using UINavigationController in the first case, but your whole navigation system is still built upon UINavigationController in the following way:
Your app has one instance of UINavigationController.
Your initial UIViewController (the one with the three buttons), is the rootViewController of your UINavigationController.
You can navigate to the other view controllers using [self.navigationController pushViewController:newViewController] (or performSegue if you prefer using Storyboards).
In the case of your third view controller, you are pushing a UITabBarController onto the navigation controller's view controller stack, this UITabBarController needs to be initialized with the two view controllers that it is going to display before it gets pushed onto the stack.
I am currently working on a project for the iPad using Storyboards for the 1st time and I am wondering if my approach is the correct way to do this.
The first ViewController in this example is actually a split view controller.
Currently within the iPad app when a user clicks on the Export Features Button I am conditionally requesting the segue based on some code / checks I am running
[self performSegueWithIdentifier:#"subscribe" sender:self];
[self performSegueWithIdentifier:#"filterOptions" sender:self];
[self performSegueWithIdentifier:#"showExportedDoc" sender:self];
However I am not sure if I should have 3 navigation controllers and also when a user clicks on the Buy button in the subscribe View Controller it pushes to the Filter Options View which is actually nested in another Navigation Controller.
Any help / advice on this would be great as I mention I am just not sure if I am following the best approach with this.
Thanks
... and
also when a user clicks on the Buy button in the subscribe View
Controller it pushes to the Filter Options View which is actually
nested in another Navigation Controller.
Well, I think you have some misunderstanding here. The fact that the filter options view controller is embedded within a navigation controller in your storyboard doesn't mean that it will be instantiated with the UINavigationController when you're pushing it within the current navigation controller (It will be so though if you connect the segue to the UINavigationController that it's embedded into).
To answer your original question, I don't see right and wrong approach here. It all depends on the structure you would like to have. For me, I guess I would prefer to have only one UINavigationController that manages everything (set it as an initial view controller and embed your home view controller within it). This would provide a more consistent navigation experience to the user, plus more consistent look (navigation bar would be shown from the beginning).
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.