Given the UINavigationController delegate methods:
-(void)navigationController:(UINavigationController*)navigationController (will/did)ShowViewController:(UIViewController*)viewController animated:(BOOL)animated
How do you tell or compare which view controller instance is relevant to the event?
I am developing an app that renders touch-navigable graphs using OpenGL. The root view contains the graph, and pushed navigation controllers contain options. I'd like to disable animation(rendering) of the graph when the user navigates away from it and re-enable it when they return.
(I know rendering should be done after the touch events and not constantly with an on/off; the template openGL code I built the app on doesn't make that an easy change but I'll get around to it eventually!)
(Oh another thing; it's a tab bar app with a navigation controller on each tab. For some reason view(did/will)(appear/disappear) events only seem to get fired when changing tabs, not the position on navigation controller stack.)
Fixed with the following:
if(viewController == [self.viewControllers objectAtIndex:0])
{
NSString* bob = #"Your uncle";
}
Thanks for your direction.
You would keep a list of ViewControllers and then compare to the one that is being shown.
You can compare by just comparing the references
for(UIViewController *vc in viewControllerArray)
{
if(vs == viewController)
//do stuff
}
Does this help or did i misunderstand something?
Related
I'm sure this has been asked countless times, and I've seen similar questions though the answer still eludes me.
I have an application with multiple view controllers and as a good view controller does its own task. However I find myself stuck in that I can't switch from one view controller to another. I've seen many people say "use a navigation controller" but this isn't what I want to use due to the unwanted view elements that are part and parcel to view controller.
I've done the following and have had limited success. The view controller is switched but the view does not load and I get an empty view instead:
- (IBAction)showLogin:(id)sender
{
PPLoginViewController *login = [[PPLoginViewController alloc] initWithNibName:#"PPLoginViewController" bundle:nil];
PPAppDelegate *appDelegate = [UIApplication sharedApplication].delegate;
appDelegate.window.rootViewController = login;
[self.view insertSubview:login.view atIndex:0];
}
Using UINavigationController as a rootViewController is a good tone of creating iOS application.
As i understand unwanted view elements is a navigationBar? You can just hide it manually, setting:
[self.navigationController setNavigationBarHidden:YES];
And about your case, if you want to change you current viewController(targeting iOS 6), you can just present new one:
[self presentViewController:login animated:YES completion:nil];
or add child (Here is nice example to add and remove a child):
[self addChildViewController:login];
Why to set UINavigationController as a root?
1) First of all it makes your application visible viewcontrollers to be well structured. (Especially it is needed on iPhone). You can always get the stack and pop (or move) to any viewController you want.
2) Why I make always make navigation as a root one, because it makes the application more supportable, so to it will cost not so many code changes to add some features to the app.
If you create one (root) viewcontroller with a lot of children, or which presents other viewcontrolls, it will make your code really difficult to support, and make something like gode-object.
Listen to George, UINavigationController is the way to go. Your reasons for not wanting to use it are not valid.
However, the reason your code doesn't work might have to do with the unnecessary line after setting the rootViewController to the login vc.
Per Apple's documentation, setting rootViewController automatically sets the window's view to the view controller's view.
I have a navigation based app. In a certain screen, I need to check from which screen the user came. I thought about something like
NSArray *viewControllers = [self.navigationController viewControllers];
int viewControllersSize = [viewControllers count];
if ([[viewControllers objectAtIndex:viewControllersSize-2] nibName] == #"Name") {
...
}
But the problem is that if the user clicks "back" from a certain screen, the view controller will be removed from the array defined above.
My current solution is having a global variable that tells me if the user came from a specific screen, but I suppose there is a more elegant solution, right?
Not sure what you meant with:
But the problem is that if the user
clicks "back" from a certain screen,
the view controller will be removed
from the array defined above.
Not all view controllers use same navigation controller?
If same UINavigationController is used for all UIViewControllers, you can use UIViewController parentViewController for this purpose. If going the opposite way, keeping reference to view controller you came from or maybe just [viewController class] (to string) would do the trick.
I'm very new to xCode and objective-C so I wanted to make a simple textRPG.
I'm currently making a character creation process consisting of 4 xib-files. The only way I got switching views to work was to look at the utility-template. Problem is, now I have the first screen being the delegate for the second screen, being the delegate for the third screen etc. So by the end of the character creation process I can't dismiss the views because that just "steps back" through the views.
When I've searched around for a solution I've found a addSubview-method but it seems like that makes a new view, like, empty to arrange programmatically.
All I need is a simple way to switch from one loaded xib to another xib. Have I misunderstood addSubview or do I need something completely different?
(If it helps: I've worked with VB for several years, in case you notice that I missed some kind of concept concerning views and such)
Thanks in advance! :)
Use this code. It is really simple and works well.
View *view = [[View alloc] initWithNibName:#"xibNameGoesHere" bundle:nil];
view.modalTransitionStyle = UIModalTransitionStyleFlipHorizontal;
[self presentViewController:view animated:YES completion:nil];
This will switch to another xib file and the two views won't own one another. I am using it in my own game right now.
#Joakim Ok, this is the way I do it. I have a class called RootViewController : UIViewContoller, whose view I add directly to the window. Then I make a subclass of UIView i.e. MyView. All of my views then subclass MyView. I also make an enum for all my views. In RootViewController you should have a switchView:(int)view method that looks something like this:
-(void) switchView:(myView) view
{
[_currentView removeFromSuperview];
switch(view)
{
case titleView:
_currentView = [[TitleView alloc] initWithRoot:self];
break;
case homeView:
_currentView = [[HomeView alloc] initWithRoot:self];
break;
default: break;
}
[self.view addSubview:_currentView];
[_currentView release];
}
in #interface RootViewContoller define MyView *_currentView;
TitleView and HomeView both subclass MyView and have a common method -(id)initWithRoot:(RootViewController*) rvc.
To switch between views use [_rvc switchView:homeView];
Hope this helps :)
It is called UINavigationController. Idea is
1) You push corresponding 'next' controller into navigation controller each time user submits current screen. Bonus - you'll get 'back' button for free on each step of character creation.
2) After character is created you pop all character creation controllers from stack.
Please read View Controller Programming Guide for iOS before trying to 'switch views' and such. You'll save tons of time and nerves.
another idea is not to use interface builder at all. i have been working with iphone apps for two years now and found that interface builder really prolongs the time to actually make something. make your own root controller and think about the logic you need to navigate through the views.
just found out something: If you have a Tabbar combined with a NavigationController (that has some views on it's stack) and you double click the TabBarItem, the view pops to the first ViewController, whether you like it or not.
Is there a way to prevent this?
You probably should not prevent this behavior. It's a standard iPhone UI convention, like tapping the status bar to scroll to the top of a scroll view.
If you really want to do it, you should implement the UITabBarController delegate method -tabBarController:shouldSelectViewController:, like mckeed mentioned. If you have more than five tabs, however, the selectedViewController may be a view controller that is in the "More" section, but vc will be [UITabBarController moreNavigationController]. Here's an implementation that handles that case:
- (BOOL)tabBarController:(UITabBarController *)tbc shouldSelectViewController:(UIViewController *)vc {
UIViewController *selected = [tbc selectedViewController];
if ([selected isEqual:vc]) {
return NO;
}
if ([vc isEqual:[tbc moreNavigationController]] &&
[[tbc viewControllers] indexOfObject:selected] > 3) {
return NO;
}
return YES;
}
I just ran into this problem myself and found a way to do it. Make a delegate for your UITabBarController and implement tabBarController:shouldSelectViewController: to prevent selecting the same controller:
- (BOOL) tabBarController:(UITabBarController *)tbc shouldSelectViewController:(UIViewController *)vc {
return tbc.selectedViewController != vc;
}
You can also add more complicated logic if you only want to prevent it in some cases.
The only way I've found so far is to make a subclass of UINavigationController and overwrite the popToRootViewControllerAnimated method to return nil.
This seems to be the method which the UITabBar calls when tabbed twice. I don't know if it's the correct way though... Would love some feedback on the issue...
- (NSArray *)popToRootViewControllerAnimated:(BOOL)animated {
return nil;
}
I agree with keeping this as-intended behavior, but at the same time things get interesting with unwinding the VC stack gracefully (such as when editing a nested series of Core Data objects). In my case, it's tantamount to canceling each VC.
Thus, is there some way for me to know we're popping all the way up to the root VC? I'm thinking a cancel/rollback op during viewWillDisappear doesn't cut it, because that same view would surely disappear after a save as well. I need to somehow broadcast "we're canceling - bail out!" when popping all the way to the root VC in a given tab. Checking a dirty/new flag as a safety check within viewWillDisappear also doesn't help, since that test would then be called twice in the case of a legit cancel (that is, if the cancel button is actually tapped).
So I have a stack of three UITableViewControllers, each of which displays its view correctly underneath the navigation bar when I tap through the UI manually.
However, now I'm working on restoring state across app restart, and so I'm pushing the same two controllers on top of the root view controller, one at a time, in the same method in the main thread. What ends up happening then is that the middle controller's view is laid out too far down, and the top controller's view is too far up (underneath the nav bar).
Relevant code:
for (int i = 0; i < [controllerState count]-1; i++) {
MyViewController* top = (MyViewController*)navigationController.topViewController;
int key = [[controllerState objectAtIndex:i] integerValue];
[top restoreNextViewController:key]; // this calls pushViewController:
// so top will be different in the next iteration
}
I suspect that the problem is that I'm not allowing some important UI refresh process to take place in between the two pushes, because they happen in the same thread. It almost looks as though the automatic view adjustment that's supposed to affect the top controller affects the middle one instead.
Is that right? And if so, what should I do, since I do want all the state-restoration to take place immediately upon app start?
EDIT: looks like I was unclear. restoreNextViewController: is a MyViewController subclass method that restores the controller's state based on a stored key, and then pushes the appropriate child controller with [self.navigationController pushViewController:foo animated:NO]. I'm doing this because my actual app, unlike this simplified case, has up to 6 controllers in the stack, and they're not always the same ones. So I figured this would be a cleaner design than going down the stack checking controllers' classes. Each controller already knows how to push a child controller in response to user input; why not reuse that on app restart?
I'm not having any trouble getting the controllers to show up; they're just being laid out strangely.
Have you considered having each view controller push its child during viewWillAppear:? I would just set an isRestoringState property in your appDelegate and check that during viewWillAppear:, if it's set, run your restore for that view, including pushing any visible child view. Something like:
- (void)viewWillAppear:(BOOL)animated {
if ([[UIApplication sharedApplication] isRestoringState]) {
// restore local state, set myChildController if a child is visible
if (myChildController) {
[self.navigationController pushViewController:myChildController animated:NO];
}
}
}
You can call pushViewController:animated: multiple times. Please post the code for -restoreNextViewController. It's confusing why this code is as complex as it is. Have you read the section of the View Controller Guide on Creating a Nav Controller? They cover pushing view controllers on the stack at startup.
I agree with Rob, I would look at implementing UINavigationController when your application is loaded. Then you would push each of your controllers onto UINavigtionController in the sequence you want them layered.
- (void)pushViewController:(UIViewController *)viewController animated:(BOOL)animated
So if you know what state you want to bring your application back to you could load the appropriate ViewController in the series to be latered and push them onto the NavigationController.
UIViewController *myViewController = [[UIViewController alloc] initWithNibName:#"myView" bundle:nil];
[navigationController pushViewController:myViewController animated:NO];
Then if you want to "pop" back to the UIViewController either the user can press the "Back" button on navigationbar for free. Or you can control the navigation with
- (UIViewController *)popViewControllerAnimated:(BOOL)animated
eg [[self navigationController] popViewControllerAnimated:NO];
You can also control whether you want the NavigationBar to show or not if you want to control the push/pop yourself. I hope I've explained this well enough I've just traveled this road recently myself.
I ended up manually resetting each table view's content inset during its controller's viewWillAppear:.