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.
Related
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 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.
So UIKit Framework Reference describes UINavigationController as an efficient way to present data and views to user. But I'm curious as to the performance and manageability differences between using UINavigationController VS SegueOnly.
There must be certain situations that one is better-suited than the other. I am entirely new to coding but instinctually I imagine UINavigationController is more for presenting VC's that each have a lot going on and user spends much time on each VC equally or that multiple VC's need to be running and holding data at same time. And that Segue are more for Uni-directionally VC progression or short-use, low-data VC presentations. Are any of these assumptions correct?
What are the PROS to implementing a UINavigationController?
This is an Apples to Socket-wrenches comparison. A navigation controller versus a segue isn't even an option. They don't fill the same role. You can use a navigation controller with or without using segues. You can use segues with or without a navigation controller.
A UINavigationController is a specific type of view controller. Specifically, it is designed for controlling a navigation stack of view controllers. When a user moves forward through your app, you add other view controllers to this navigation stack (either through segues or through other methods available on the view controller to present other view controllers). Meanwhile, the navigation controller allows you to "pop" controllers off the stack and we go backward to the previous view controller.
When we're comparing a UINavigationController to things, we should compare it to things like UITabBarController, or UISplitViewController, or UIPageViewController. These are other types of view controllers that control the way in which a user navigates through our app.
Segues exist as a means to get from one view controller to another. But the various controllers I just listed exist as a means for controlling the navigational relationship between your controllers.
If you are using storyboards for building your app, I highly recommend that you use segues. Whether or not you use a navigation controller is entirely up to the way you want your application navigation to work.
Perhaps some pictures might make the distinction more clear?
Exhibit A
Here we have two view controllers. No navigation controller, nothing. Just two normal controllers. The line with the arrow between the view controllers is the segue. The segue defines a relationship between the view controllers which lets us get from the one on the left to the one on the right.
Exhibit B
Here we have a navigation controller, followed by two view controllers. The line between the navigation controller (far left) and the first view controller (middle) is not a segue. However, it does define a relationship between the navigation controller and the view controller. It defines the view controller as the navigation controller's root view controller. Whenever we present this navigation controller, it will in turn present this view controller as the first controller on its navigation stack. The line between the first view controller (middle) and the second view controller (far right), however, is a segue. It's identical to the segue from exhibit A (except exhibit A is probably a different type of segue). This segue defines a relationship between the first and second view controller and provides us with a means of getting from first to second.
Exhibit C
Here we have a tab bar controller (far left) and four view controllers. We also have a bunch more lines connecting these things. Much line in the navigation controller example, the lines between the tab bar controller and the view controllers are NOT segues, but they do define a relationship between the tab bar controller and the view controllers. These lines assign the view controllers as part of the tab bar controller's viewControllers array, which determines what tabs to display. The lines between the left view controllers and the right view controllers, however, are segues, exactly the same as the first two examples.
A segue is nothing more than a way of defining a navigational relationship between two view controllers on your storyboard. If you weren't using a storyboard, you also wouldn't be using segues at all, but you could still make your app navigate in the exact same manner (this can all be achieved programmatically without the storyboard and without segues--and I don't think it effects performances on way or another).
Whether or not to use a navigation controller is another question and an entirely separate question at that. Whether or not to use a navigation controller isn't even remotely in the same ballpark to whether or not you're using segues. Using a navigation controller also isn't a question of performance. The overhead for using a navigation controller is extraordinarily minor. Most of the overhead for it probably comes from the UI stuff it adds... but if you want that UI stuff, you're going to have that overhead whether or not you have a navigation controller.
Importantly, whether or not to use segues isn't a question of performance--it's merely a question of whether or not you're designing your app using storyboards. And equally importantly, using navigation controllers isn't a question of performance--it's a question of how you want your app's navigation to look and feel. "Is a navigation controller the right look and feel for your app?" is literally the only question you have to answer when deciding whether or not to use a navigation 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.
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.