I'm breaking my head for the last one week on how to solve the issue with showing and dismissing multiple view controllers. I have created a sample project and pasting the code directly from the project. I have 3 view controllers with their corresponding .xib files. MainViewController, VC1 and VC2. I have two buttons on the main view controller.
- (IBAction)VC1Pressed:(UIButton *)sender
{
VC1 *vc1 = [[VC1 alloc] initWithNibName:@"VC1" bundle:nil];
[vc1 setModalTransitionStyle:UIModalTransitionStyleFlipHorizontal];
[self presentViewController:vc1 animated:YES completion:nil];
}
This opens VC1 with no issues. In VC1, I have another button that should open VC2 while at the same time dismiss VC1.
- (IBAction)buttonPressedFromVC1:(UIButton *)sender
{
VC2 *vc2 = [[VC2 alloc] initWithNibName:@"VC2" bundle:nil];
[vc2 setModalTransitionStyle:UIModalTransitionStyleFlipHorizontal];
[self presentViewController:vc2 animated:YES completion:nil];
[self dismissViewControllerAnimated:YES completion:nil];
} // This shows a warning: Attempt to dismiss from view controller <VC1: 0x715e460> while a presentation or dismiss is in progress!
- (IBAction)buttonPressedFromVC2:(UIButton *)sender
{
[self dismissViewControllerAnimated:YES completion:nil];
} // This is going back to VC1.
I want it go back to the main view controller while at the same time VC1 should have been removed from memory for good. VC1 should only show up when I click on the VC1 button on the main controller.
The other button on the Main view controller should also be able to display VC2 directly bypassing VC1 and should come back to the main controller when a button is clicked on VC2. There is no long running code, loops or any timers. Just bare bone calls to view controllers.
This line:
isn't sending a message to itself, it's actually sending a message to its presenting VC, asking it to do the dismissing. When you present a VC, you create a relationship between the presenting VC and the presented one. So you should not destroy the presenting VC while it is presenting (the presented VC can't send that dismiss message back…). As you're not really taking account of it you are leaving the app in a confused state. See my answer Dismissing a Presented View Controller in which I recommend this method is more clearly written:
In your case, you need to ensure that all of the controlling is done in
mainVC
. You should use a delegate to send the correct message back to MainViewController from ViewController1, so that mainVC can dismiss VC1 and then present VC2.In
VC2VC1 add a protocol in your .h file above the @interface:and lower down in the same file in the @interface section declare a property to hold the delegate pointer:
In the VC1 .m file, the dismiss button method should call the delegate method
Now in mainVC, set it as VC1's delegate when creating VC1:
and implement the delegate method:
present2:
can be the same method as yourVC2Pressed:
button IBAction method. Note that it is called from the completion block to ensure that VC2 is not presented until VC1 is fully dismissed.You are now moving from VC1->VCMain->VC2 so you will probably want only one of the transitions to be animated.
update
In your comments you express surprise at the complexity required to achieve a seemingly simple thing. I assure you, this delegation pattern is so central to much of Objective-C and Cocoa, and this example is about the most simple you can get, that you really should make the effort to get comfortable with it.
In Apple's View Controller Programming Guide they have this to say:
If you really think through what you want to achieve, and how you are going about it, you will realise that messaging your MainViewController to do all of the work is the only logical way out given that you don't want to use a NavigationController. If you do use a NavController, in effect you are 'delegating', even if not explicitly, to the navController to do all of the work. There needs to be some object that keeps a central track of what's going on with your VC navigation, and you need some method of communicating with it, whatever you do.
In practice Apple's advice is a little extreme... in normal cases, you don't need to make a dedicated delegate and method, you can rely on
[self presentingViewController] dismissViewControllerAnimated:
- it's when in cases like yours that you want your dismissing to have other effects on remote objects that you need to take care.Here is something you could imagine to work without all the delegate hassle...
After asking the presenting controller to dismiss us, we have a completion block which calls a method in the presentingViewController to invoke VC2. No delegate needed. (A big selling point of blocks is that they reduce the need for delegates in these circumstances). However in this case there are a few things getting in the way...
present2
- you can end up with difficult-to-debug errors or crashes. Delegates help you to avoid this.So please... take the time to learn delegation!
update2
In your comment you have managed to make it work by using this in VC2's dismiss button handler:
This is certainly much simpler, but it leaves you with a number of issues.
Tight coupling
You are hard-wiring your viewController structure together. For example, if you were to insert a new viewController before mainVC, your required behaviour would break (you would navigate to the prior one). In VC1 you have also had to #import VC2. Therefore you have quite a lot of inter-dependencies, which breaks OOP/MVC objectives.
Using delegates, neither VC1 nor VC2 need to know anything about mainVC or it's antecedents so we keep everything loosely-coupled and modular.
Memory
VC1 has not gone away, you still hold two pointers to it:
presentedViewController
propertypresentingViewController
propertyYou can test this by logging, and also just by doing this from VC2
It still works, still gets you back to VC1.
That seems to me like a memory leak.
The clue to this is in the warning you are getting here:
The logic breaks down, as you are attempting to dismiss the presenting VC of which VC2 is the presented VC. The second message doesn't really get executed - well perhaps some stuff happens, but you are still left with two pointers to an object you thought you had got rid of. (edit - I've checked this and it's not so bad, both objects do go away when you get back to mainVC)
That's a rather long-winded way of saying - please, use delegates. If it helps, I made another brief description of the pattern here:
Is passing a controller in a construtor always a bad practice?
update 3
If you really want to avoid delegates, this could be the best way out:
In VC1:
But don't dismiss anything... as we ascertained, it doesn't really happen anyway.
In VC2:
As we (know) we haven't dismissed VC1, we can reach back through VC1 to MainVC. MainVC dismisses VC1. Because VC1 has gone, it's presented VC2 goes with it, so you are back at MainVC in a clean state.
It's still highly coupled, as VC1 needs to know about VC2, and VC2 needs to know that it was arrived at via MainVC->VC1, but it's the best you're going to get without a bit of explicit delegation.
I have solved the issue by using UINavigationController when presenting. In MainVC, when presenting VC1
In VC1, when I would like to show VC2 and dismiss VC1 in same time (just one animation), I can have a push animation by
And in VC2, when close the view controller, as usual we can use:
Example in Swift, picturing the foundry's explanation above and the Apple's documentation:
ViewController.swift
ViewController1.swift
ViewController2.swift
ViewController.swift
ViewController1.swift
ViewController2.swift
I think you misunderstood some core concepts about iOS modal view controllers. When you dismiss VC1, any presented view controllers by VC1 are dismissed as well. Apple intended for modal view controllers to flow in a stacked manner - in your case VC2 is presented by VC1. You are dismissing VC1 as soon as you present VC2 from VC1 so it is a total mess. To achieve what you want, buttonPressedFromVC1 should have the mainVC present VC2 immediately after VC1 dismisses itself. And I think this can be achieved without delegates. Something along the lines:
Note that self.presentingViewController is stored in some other variable, because after vc1 dismisses itself, you shouldn't make any references to it.
I wanted this:
MapVC is a Map in full screen.
When I press a button, it opens PopupVC (not in full screen) above the map.
When I press a button in PopupVC, it returns to MapVC, and then I want to execute viewDidAppear.
I did this:
MapVC.m: in the button action, a segue programmatically, and set delegate
PopupVC.h: before @interface, add the protocol
after @interface, a new property
PopupVC.m:
Radu Simionescu - awesome work! and below Your solution for Swift lovers: