Is my assumption that every controller which is presented with presentModalViewController:animated: need their own UINavigationController stack for their own hierarchy of drill down controllers? Meaning, say I have a top level controller It has its own navigation stack, and an action button which presents another controller via a modal. That modal has its own navigation stack. Is it best to split each modalView with its own Navigation stack?
If you want a modal view to have the forward-and-back behavior provided by a navigation controller, you need to provide a separate navigation controller for it. (If you don't need to push and pop view controllers inside that modal view, then you don't need one, of course.) This can be a bit of a pain, but them's the breaks.
Related
I'm working on a project which has multiple view controllers stacked in a navigation controller, similar to this:
https://youtu.be/yl2m4fDOLQo
I fear that I may end up stacking too many view controllers in one navigation controller. I understand that once there are more than 3 view controllers stacked in a navigation controller, the views are presented "modally"
First of all, what is a "modal" presentation? I looked it up in Swift documentation but I'm having some trouble understanding how it differs from the navigation stack. Second, if there is a problem, is there any way around it?
I'm new to this so help is much appreciated,
Nick
I understand that once there are more than 3 view controllers stacked in a navigation controller, the views are presented "modally"
This is false. You can have as many view controllers in a navigation stack as your app needs, as long as the device has enough memory. View controllers in a navigation stack have a navigation bar (technically, this is part of the navigation controller), a back button and (hopefully) a swipe-right gesture that allow the user to go back "up" the stack. You add a view controller to the stack by calling pushViewController(animated:) and remove it by calling popViewController(animated:) on the navigation controller.
A modal view controller exists outside of the navigation stack. It does not have a navigation bar because it's not in a navigation controller. You are responsible for adding some way to dismiss the modal, such as tapping a close button placed manually in the view controller's view somewhere. You can even add a navigation bar instance manually and put a close button in it. You show a modal by calling present(_:animated:completion:) on the currently-displayed view controller and dismiss it by calling dismiss(_:animated:completion:).
I have an iPhone / iPad application that manages its numerous view controllers via a UINavigationController and UITabViewController. The UINavigationController handles the majority of the user interaction and the UITabViewController handles user settings/preferences.
My app delegate initializes the UINavigationController and pushes the first view controller. Settings (the UITabViewController) can be accessed via a button on the navigation controller's menu bar; the user can return to the main application (the UINavigationController) via a button on the UITabViewController.
My question is: what should I be doing with the UINavigationController (and its stack of view controllers) when I show the UITabViewController and vice-versa? Is there any reason to remove/release/recreate each parent controller as the user switches between the two, or should I be adding/removing each parent controller's view to my app's window?
It seems that the first option would be more mindful of memory/resources, however these benefits might get overshadowed by the processing cost to re-alloc/init the view controllers each time.
Thanks.
You do not have to manage the navigation controller's stack manually. What I would do is present your settings view controller as a modal view. You would do this at the navigation controller level.
Assume that settingsViewController is a property of your main view controller.
self.settingsViewController.modalTransitionStyle = UIModalTransitionStyleFlipHorizontal
[self.navigationController presentModalViewController:self.settingsViewController animated:YES];
I assume you mean UITabBarController.
If your navigation view would show up in the tab view for a tab item, I would suggest let the tab bar controller to be the root view controller of your application (and therefore always seen in the app).
If your navigation view is the main view, and the user simply opens up the tab bar view for settings etc. and will return for the navigation view, then modally presenting the tab bar controller is the right way.
In the first case (the navigation controller IN the tab bar controller), you would not care for adding/removing or allocating/releasing views as the UIKit will manage it for you.
In the second case you may create a tab bar controller when you want to show it. presentModalViewController will retain the view controller so you can release it immediately after you send the message. If you want to hold the view controller then you create one when the application is loaded and retain it in the navigation controller (and the navigation controller will always remain in the memory).
Let's say you have a tab view controller on the navigation controller view stack. (For the sake of argument.) Your tab controller has an array of view controllers for each of its tab views. Your tab controller's navigationController is clearly set to the nav controller (since its view is on the stack.)
But would you set the navigationController for each of your tab views to point to the nav controller? Their views aren't actually on the nav stack (they are subviews to the tab view that is), but it's necessary for them to be able to push a view onto said stack. Is it a bad idea? Should I do this but use a different instance variable?
Or would you just maintain pointers from all the subviews to their parent view controllers all the way up to the navigation controller? That seems clumsy and not that great if you have to go more than one level deep (which I do.)
(I'm not precisely doing this, I have a complex view with dedicated controllers for its subviews, so this is an accessible analogy.)
I find I am more successful when I keep separate navigation controllers for each tab. Then they can operate independently, and keep state when the user switches across tabs. Then there is no confusion about which view controllers are on the stack are below, or visible at a given point in time.
As for keeping pointers among the views and controllers, do not confuse the view hierarchy with the view controller stack, they are only orthogonally related as far as your view controller stack is concerned. There is a natural "ownership" of views by their view controllers, and you shouldn't have to be manipulating those pointers yourself, that should fall out naturally from the loading and creating of views, and view controller stack management API calls.
I have a Navigation Controller with a root table view which has several links. Tapping each link moves to the next view (by pushing it to the navigation controller's stack). But suppose that in that "next view", I have a UIButton that should take me further to another view (by pushing on to the same navigation controller's stack)...
View Controller-->first view-->second view-->third view..........
Now, I can easily access the Navigation Controller when I deal with the first view (and successfully push it to the Navigation Controller's stack) because it has been instantiated in the same file itself. What my real doubt is--How do you access a Navigation Controller in a far off view controller (eg, the third view or fourth view etc)? Please note that I am not using any separate delegate. All the Navigation Bar methods have been implemented in one file and connected to the Navigation Controller via an outlet.
When you push a ViewController onto a NavigationController the ViewController will automatically have it's navigationController property set. This means you can access the same NAvigationController no matter where you are in the stack.
-Update-
navigationController
In every UIViewController you can access that property.
So to in any other UIViewController that has been pushed onto the stack you should be able to just do this:
[self.navigationController pushViewController:othercontroller animated:YES];
Look at the documentation for UIViewController to see what other magic properties you have available.
I'm starting an app where I'd like to have multiple view controllers. Some of the views will be displayed inside of a navigation controller. I can create a navigation controller and then add another instantiated view controller to it. But what I'd like to do, is just instantiate a view controller that has its own view and is the root view controller of a navigation view controller. So when I instantiate the view controller, I'd like for it create a navigation controller and push "self" on to it. When I do it my simulator crashes and the details don't really give a reason. The console does not display anything. Any ideas. My reason for this is to separate out logic without have a view controller that simply creates a navigation controller and then pushes another view controller on it as the root view controller.
I'm not entirely sure if I understand your question correctly. Why would it be preferable if the view controller pushed itself to the navigation controller? I mean, you have to instantiate your view controller at some point in code (either app delegate or another view controller) anyway. Why can't you just create the navigation controller there, instantiate your VC and then push it onto the nav controller? As far as I can see, this doesn't involve creating any additional view controllers.
Anyway, having a view controller decide by itself where it is used (ie. pushed onto), is not best practice. This way you lose the flexibility of using it in other contexts. Always try to couple your components as loosely as possible.