I am trying to do if user give correct password it will go back to the current last view controller where i was,like in Ios if u enter background in your app and after sometime you enter foreground then you will go back to the last view i.e where you was before entering background.please tell me how to implement this.
if you want to pop to the root controller you can use popToRootViewControllerAnimated.
[self.navigationController popToRootViewControllerAnimated:YES];
From Apple doc of UINavigationController
popToRootViewControllerAnimated:
Pops all the view controllers on the stack except the root view controller and updates the display.
- (NSArray *)popToRootViewControllerAnimated:(BOOL)animated
If you have set up a UINavigationController and its root controller is called A, then if you navigate from A to B and then from B to C you have two possibilities to come back to a previous controller (you can have others but I list the main ones):
navigate back from C to B with popViewControllerAnimated
navigate back from C to A with popToRootViewControllerAnimated
I would suggest using a modal view controller that is not actually added to you parent controllers hierarchy (child view controllers) and can be shown and dismissed at your discretion take a look here for a great example.
Related
I am using a tabbar, each tab having a navigation controller, and this in turn having a stack of views. Each view is having its own view controller but this is not important now.
Lets have a tab 1 with a navigation controller 1 with views A, B, C.
The nature of the application dictates however that the view B is the primary one.
So what I want is that by default (after first or after relaunch of the app), when I tap the tab 1, I will see the B view together with the back button to A view.
How can I achieve this?
You can set up a delegate for your tab bar controller and implement tabBarController:didSelectViewController: to detect when someone taps a tab. If you detect that A is about to be selected and you want B to be displayed instead, you can tell A's controller to use its navigation controller to push B's controller.
Try initializing and pushing view B (without animation) onto the navigation stack in viewDidLoad of view A.
You could use the setViewControllers:animated: of UINavigationController.
Depending on your exact needs you could set this in your app delegate applicationWillEnterForeground: or applicationDidBecomeActive: methods.
I recall there being an Apple sample app that does exactly this. The general idea is to save the last visible view controller (or just hard code the one you want) and then push it to the visible state using something like so:
[myNavigationController pushViewController:viewControllerToBeVisible animate:NO];
You'd want to show the apps tabBarController:didSelectViewController:, and handle the different cases based on which viewController was selected.
Is this even possible? I have 3 UIViewControllers: The main screen (A), the screen the user tapped a button to get to (B), and the login screen (C). If the user isn't logged in, it will go from A -> C and when they log in it should go from C -> B but I need to present B underneath C and before C is dismissed.
If you are calling the UIViews of the button and login screen from main screen you can do [self.view sendSubViewToBack:subview];
You can present a view controller modally with no animation.
[self presentViewController:viewControllerC animated:NO completion:nil];
You can do this in didFinishLaunchingWithOptions: which means your login view controller will appear right after launch. And then when the user has successfully logged in, you simply call
[self dismissModalViewControllerAnimated:YES];
on the C view controller (or whichever one is the login one) and it slides down to reveal the main application. It's a cool effect. You can also choose to change the transition style of the view controller to have it flip around horizontally to reveal the app after a login, etc.
viewControllerC.modalTransitionStyle = UIModalTransitionStyleCoverVertical;
You could present C in a modal view from A
And Push B before dismissing C.
That's if you want to use a modal presentation of C (which seems better to me).
Even if it's not the case, you could still change the viewControllers of the navigationController just after C appeared or just before it start disappearing.
I've set up a really simple project using storyboards including two views as shown here: http://i.stack.imgur.com/iRx21.png. The navigation can be done by either selecting a cell in the custom table view or hitting the back button labelled with "<<". Everything works fine except the following:
when I switch between the views, every time an instantiation happens. The profiling shows an increasing number of view objects. I would like to keep only one of each view and instantiation should be happen only once. What am I doing wrong? (I'm using ARC.)
Thanks in advance!
You should not link your back button to the parent view controller. This is what causes the new instantiation.
The way to go is to embed the table view into UINavigationController (in IB, choose Editor -> Imbed In -> Navigation Controller. Then change your segue to a Push segue. You can of course hide the navigation bar etc. to make things look exactly as you like. Then, link the back button to the controller with an IBAction and in the handler do a simple
[self.navigationController popViewControllerAnimated:YES];
This would be the appropriate logic of what you are doing. Of course, you can also push the web view modally and then handle the button click with
[self dismissModalViewControllerAnimated:YES];
Hi there and thank you in advice for your help. I have a really strange problem while working with ViewControllers in Xcode4. First of all I have to say that I'm not using storyboards and I prefer to create any UI element programmatically. So I've set a UIButton and I want that, when pressed, it brings me to a new view controller. This is the code I'm using for a button:
-(void)settingsAndExportHandle:(UIButton *)buttonSender {
SettingsViewController* settingView = [[SettingsViewController alloc] initWithNibName:#"SettingsViewController" bundle:nil];
settingView.modalTransitionStyle = UIModalTransitionStyleFlipHorizontal;
[self presentModalViewController:settingView animated:YES];
}
This buttons is initialized and allocated in the viewDidLoad method of the RootViewController. I want to switch to the other view controller (in this case SettingsViewController) when I press the button.
The strange thing is that when I press the button, the animation that flips the controllers goes well, but when it finishes I obtain the EXACT same things that I had on the RootViewControllers (same custom views, same buttons, same all!). The question is: what I'm missing?? I have to say that I use ARC (automatic reference counting) so I can't release or dealloc the views and buttons I've created on my RootViewController.
Any help will be appreciated. Thank you all!
Pushing and and modally presenting view controllers does not deallocate the view controller that presented them. It simply adds the additional view controller to the stack. You'll need to implement a callback method so that when the user hits the button to flip back to root view controller, your settings view controller lets the root view controller know what's about to happen so you can call a method you've written to reset the interface back to whatever state you need it at. You may also be able to use viewWillAppear: but that's a little messy.
However, according to the Apple Human Interface Guidelines, the user expects that when they push a view controller or modally present it, the view controller they were on will save state and be exactly the way they left it when they came back. It's disconcerting and annoying when state is not preserved while in a navigation controller context. It is especially annoying when it's modally presented.
Think about this - A user is in a hypothetical Mail app. They start typing out an email and set a font size and a color. They tap on the add attachment button, which brings up a modal view controller that allows them to select a picture. They select the picture and the modal view is dismissed, and in your implementation, the mail composing interface would have reset and the email content would be gone or at the very least the selected font size and color would be back to the default. That's not a good experience.
Setup: I have a storyboard set up, with two simple view controllers A and B. There is a button in A, that transitions to B with a modal segue. B is presented with a modal transition on top of A. It’s fine.
Question: is there a way to pop B away and get back to A with some simple storyboard magic?
Note that if this was all in a navigation controller, and I used a push segue, it would be implicitly be taken care of by navigation controller. There would be a “back” button. There’s nothing comparable for modals, I need to build the UI myself which is fine, but I am wondering if there is a segue mechanic I can use to signal to go back from B to A.
Now the oldskool method to build going back from B to A would be:
create a delegate property on B
set A to be B's delegate when the modal transition segue plays back (I can hook into this using prepareForSegue:sender: in A’s code)
when it’s time to dismiss, B signals to its delegate
A implements a delegate method that dismisses B
This works, but feels like too much overhead and silly.
Is there some UIStoryboard mechanic that I have missed, that would basically do a “reverse modal segue”?
There isn't any storyboard magic for dismissing a modal view controller without writing at least a little bit of code.
But while you do have to implement some code of your own, you don't necessarily have to go to that much trouble. You can just have a button in view controller B that calls [self dismissViewControllerAnimated:YES completion:nil]. (The docs say the presenting view controller should be the one to dismiss, but they also say that the message will be forwarded to the presenting view controller if called on the presentee. If you want to be more explicit about it -- and you'll need to be in some cases, like when one modal view controller is presented from another -- you can explicitly reference the presenter with self.presentingViewController and call dismiss... from there.)
You see the delegate business in some apps because it's one way of notifying view controller A about whatever the user did while in view controller B... but it's not the only way. There's KVO, notifications, or just plain calling A's methods after referencing it with self.presentingViewController (assuming B knows it's always getting presented by A). And if A doesn't need to know about what happened in B (say, because the user hit a Cancel button), there's no need to do any of that -- you can just dismiss the modal and be done with it.
In iOS 6 and later, unwind segues add another option, providing a little bit of "storyboard magic" for dismissing modal view controllers (or otherwise "backing out" of a sequence of segues). But this approach still requires some code -- you can't set it up entirely in storyboard. On the plus side, though, that code provides a path for getting info from the view controller being dismissed (B) to the one that presented it (A).
Apple has a tech note about unwind segues that covers them in detail, but here's the short version:
Define an IBAction method on the view controller class you want to unwind to -- the one that presents a modal view controller, not the modal view controller itself (view controller A in your question). Unlike normal IBAction methods, these should take a parameter of type UIStoryboardSegue *; e.g.
- (IBAction)unwindToMainMenu:(UIStoryboardSegue*)sender
In the presented view controller (B in the question), wire a control to the green Exit icon, and choose the method you defined.
In your unwind method implementation, you can refer to the segue's sourceViewController to retrieve information from the view controller being dismissed. You don't need to call dismissViewControllerAnimated:completion: because the segue handles dismissing the view controller that's going away.
There is storyboard magic to achieve this. It's known as an unwind segue. In A's .h file you implement whatever "target action" style methods you need for however many unwind segues you need. For a modal, it's usually two (cancel and save). So in my A.h file I would add:
// A.h file
- (IBAction)myCancelUnwindSegueCallback:(UIStoryboardSegue *)segue;
- (IBAction)mySaveUnwindSegueCallback:(UIStoryboardSegue *)segue;
Now, in your storyboard, if you have a segue from A to B. You can now do a "target action" style control drag from your cancel/save buttons in B to the green "Exit" icon at the bottom of the B controller in your storyboard. When you do this, Xcode will pick up the two methods we created (since they're in A's header file and they have the correct signature (e.g. IBAction and UIStoryboardSegue *.) and B is the destination of a segue from A) So, there you have it. You have the storyboard magic you were looking for!
In the implementation of the two callbacks, you would have something such as:
// A.m file
- (IBAction)myCancelUnwindSegueCallback:(UIStoryboardSegue *)segue {
UIViewController *modalGoingAway = segue.sourceViewController;
// Do something (like get data) from modalGoingAway if you need to...
}
- (IBAction)mySaveUnwindSegueCallback:(UIStoryboardSegue *)segue {
UIViewController *modalGoingAway = segue.sourceViewController;
// Do something (like get data) from modalGoingAway if you need to...
}
Lastly, if this approach meets your needs, great. You're done. However, I still wire up the whole protocol delegate/dataSource design pattern if "on cancel" or "on save" I want to perform some operations on B's private properties before passing control over to A to remove B from the view hierarchy.