I am using a UINavigationController within my app (as expected) for a specific path the user takes when taking a turn in my turn based game.
When they move through the turn controllers they do not actually have the option to go Back from the Navigation Controller. This is planned/expected behaviour.
My question is, is it best to keep the other controllers on the UINavigationController stack when they are not going to be used again.
Should they be de-alloced immediately, or wait for the whole turn to be complete and let them go when the navigation controller goes (how it is at the moment). Some of the controllers hold data/images etc as properties so I am wondering if it would be more efficient to get rid of these on the fly?
If it is, what is the best method to load new controllers into the UINavigationController at present I am using self performSegue... or buttons that push to the VC from the storyboard setup.
You can manipulate navigation controller viewControllers using this code
NSMutableArray *viewControllers = self.navController.viewControllers;
//remove or add in the array
[self.navController setViewControllers:viewControllers];
Related
I've got a single navigation controller that houses the primary view of the app (A dashboard of sorts) which then branches off to the other views in the app via segues etc..
There's a hamburger menu, which makes use of a Cocoa Pods sliding view controller. Basically, my question is is it possible to navigate to specific view controllers via the menu and maintain the correct "stack" going back. I'm aware you can just push to a single controller, but I'd like (if possible) to retain the view hierachy going back.
E.g.
There's a link in the menu to Page 1.3
I want to be able to push to Page 1.3
Then have the back button on that view to go to Page 1.2, then Page 1.1 etc..
I'm not sure whether this is standard practice in iOS apps, or whether it's better to adopt an Android esque approach and just add views to the stack, not worrying about trying to form the correct navigation structure when they go back through the views.
Hopefully all of that makes sense.
If you are happy to do it in code, rather than a segue, you can use the UINavigationController's setViewControllers:animated: method (see the documentation). You will need to instantiate the relevant VCs, initialise them with any relevant data/state, and then build an array with them in order from the root view controller to the top view controller:
NSArray *newStack = #[rootVC, ..., page11VC, page12VC, page13VC];
[self.navigationController setViewControllers:newStack animated:YES];
Then popping from page13VC will go to page12VC, etc, etc. You can get rootVC and any other pre-existing VCs using the viewControllers property of the navigation controller.
I meet the same problem in my project,here is my experience.
If you just want to do simple jump, you can try the three basic navigation function:
[self.navigationController popToRootViewControllerAnimated:YES]
[self.navigationController popToViewController:[[self.navigationController.viewControllers count] - mypopcount] animated:YES];
[self.navigationController popViewControllerAnimated:YES];
Bind the action with the button, you can do that.
But, if you want to do more flexible page jump in ios, you must consider:
First of all, you need to confirm that there is no direct data interact between these view controllers, which means you need coreData or other sqlite tools to store data, so the destination page can load data itself.
Secondly, you should consider the strategy, page jump means pop all viewcontroller and push a new one, or just pop or push a new one just on the navigation stack.
Good Luck!
I am interested in creating an app that starts with a menu which may possibly contain an options view, then steps from the menu view to a data-item selection view, then to a configuration view, and finally a result view that displays progress or changes. I want to have this process be repeatable like a loop, and have the user be able to jump backwards to a previous view if necessary. Jumping from view to view would of course be a user input / output with a button or something. FYI, I am using Xcode 5.1.1.
What would be the best approach to this? What kind of view controller is going to do the trick? I have heard a lot about navigation controllers, tables, etc.. but am having a hard time figuring out what to use in my case.
Below is a state-diagram similar to what I would like to do...
A UINavigationController should work great as your root view controller. It automatically includes a back button, and you can use the popToRootViewController method to return to the root of the navigation controller. You can set up a navigation controller as your root view controller from the applicationDidFinishLaunching method using this code.
MainMenuViewController *mainMenuViewController = [[MainMenuViewController alloc] init];
UINavigationController *navController = [[UINavigationController alloc] initWithRootViewController:mainMenuViewController;
self.window.rootViewController = navController;
For more information take a look at apples UINavigationController programming guide https://developer.apple.com/library/ios/documentation/uikit/reference/UINavigationController_Class/Reference/Reference.html
Each of your other screens may use different types of view controllers depending on their specific needs. If you need to display a list of items, definitely look into a UITableView. Apple's documentation for a UITableViewController can be found here https://developer.apple.com/library/ios/documentation/uikit/reference/UITableViewController_Class/Reference/Reference.html
Alright I'm really failing to see what the big win in having Navigation Controllers wrap my views and trying to drag segues on my Storyboards are. Sure you get the benefit of iOS automatically adding a back button as you push/pop views off the stack, but for anything past a simple app, I don't even care for that!
My goal is simply to have 1 view actually represent a given page. Then just programatically move to another view using:
ViewController *vc = [storyBoard instantiateViewControllerWithIdentifier:#"ViewController"];
[self presentViewController:modalYearPickerViewController animated:NO completion:nil];
or
ViewController *vc = [storyboard instantiateViewControllerWithIdentifier:#"ViewController"];
[self.navigationController pushViewController:vc animated:YES];
I realize that in order to push with the second example I'd need the view to be wrapped in a Navigation View Controller, however using one of these methods prevents my from ever having to create "segues" which I find hard to manage. Half the time when I setup a segue iOS throws an error saying it cannot perform or the segue doesn't exist.
A lot of the time I'm either hiding back buttons or on the fly changing where "back/return" may drive the user based on previous actions or screens.
Anything massive I'm missing here? I am fairly new to iOS but I come from the web world where I'm used to being able to navigate around screens with ease.
Anyone have any thoughts?
EDIT: Here is a dead simple example solution. When I get to the "details" page I want to have a back button to the home page instead of the modal.
http://andrewherrick.com/spike/nav_ios.zip
From your diagram, I'd expect:
At the root, you have a navigation controller which contains the Artists. Artists has a modal segue to New Artist (well, to a nav controller containing it) and a push segue to Artist Songs.
New Artist is the root of a navigation controller and has a push segue to Artist Songs. New Artist has a Cancel and a Done button in the navigation bar.
Artist Songs should be configurable (it could determine this itself), such that it has a back button (always based on this model, and automatically handled) and a Done button when it is pushed from New Artist (which completes the save and dismisses the modal, thus taking the user back to Artists).
All of the above is a achievable either with segues or direct instantiation and transition from code, which you use is a matter of personal preference.
Is it bad practice to skip view controllers in a navigation stack?
In my example I have a UINavigationController (which is being presented modally) with three UIViewControllers (firstViewController, secondViewController and thirdViewController), most of the time the user will be accessing firstViewController, maybe tapping a row which will then load secondViewController and so on, but what if in some circumstances I want to load the second or third view controllers immediately but still keep the first view controller in the stack, so that the user can still go back to the firstViewController.
I can do this but it doesn't feel right - is this something I should avoid doing?
Yes, it's called deep-linking, and it's perfectly fine. It's quite commonly done for things like coming from an external URL or push notification.
If I have a UITabBarController (2 tabs) as root view controller then in the first tab (FirstTabViewController) I init a UINavigationController with a root view controller AddReminderViewController and present it.
Then inside AddReminderViewController I present another UINavigationController with a root view controller called ChooseOptionViewController and present it.
Now when I'm inside ChooseOptionViewController I want to programtically go back to FirstTabViewController how can I do this as easy as possible? Do I need to - dismissViewController... on all view controllers that I have presented or is there an easier way?
Also inside ChooseOptionViewController how can I find out the class that presented ChooseOptionViewController? I tried doing [self.presentingViewController class] but that just says UINavigationController (not AddReminderViewController)
Now when I'm inside ChooseOptionViewController I want to
programtically go back to FirstTabViewController how can I do this as
easy as possible?
You really ought not to have the ChooseOptionViewController try to manage all that by itself. It should simply tell its parent that its job is done and let the parent dismiss it. The parent could then tell its parent that its job is done, and so on. This approach will make it much easier to maintain your code, and to change things around when you decide that's necessary, without breaking ChooseOptionViewController.
For example, imagine that AddReminderViewController wants something else to happen, like presenting ChooseMoreOptionsViewController after ChooseOptionsViewController has been presented. If AddReminderViewController is in charge of the flow of its part of the program, that's easy. If ChooseOptionsViewController knows enough about the reset of the app to dismiss view controllers all the way back to FirstTabViewController, you'll have to modify it every time there's a change in the flow. That's not a recipe for long term success, and it adds a lot of unnecessary and unhelpful complexity.
generally unless an exception you should use only one navigation controller.
keep pushing view controllers onto it.
in that way you can move pop top to root view controller.
for ex:
1
just add one navigation controller to tab 1
2
setrootviewcontroller of navigation controller to FirstTabViewController
3
from FirstTabViewController you can push AddReminderViewController(using the same navigation controller)
ex:- [self.navigationController PushViewController:....];
4
from AddReminderViewController you can push ChooseOptionViewController(using the same navigation controller)
ex:- [self.navigationController PushViewController:....];
5 finally use [self.navigationController popToRootViewController];