Given the following view controller layout.
We build a stack of modal view controllers by first presenting B on A and then presenting C on B. According to the Apple documentation on dismiss(animated:completion:), calling it on A should actually dismiss the topmost view controller (C in this case) in an animated fashion and all intermediate view controllers without animation. What happens though is that C gets dismissed without animation and B is dismissed in an animated fashion.
I put up an Xcode project on GitHub that replicates that behaviour. Am I missing something or am I misunderstanding the documentation here?
After poking around the web and trying out various 'solutions' it is clear this is an actual bug within iOS. It has been present since iOS 8... and is still present in iOS 10. It was originally reported in iOS 8, but the solution was never validated and Apple automatically closed the radar due to inactivity.
I have filed a new radar as this is in direct contradiction to the documentation for dismissViewController
If you present several view controllers in succession, thus building a
stack of presented view controllers, calling this method(means
-[UIViewController dismissViewControllerAnimated:completion]) on a view controller lower in the stack dismisses its immediate child view
controller and all view controllers above that child on the stack.
When this happens, only the top-most view is dismissed in an animated
fashion; any intermediate view controllers are simply removed from the
stack.
Clear visualization of the issue, both expected and actual results. Credit to Boris Survorov for the test project and visualizations.
I've experienced the same issue and here is what I've found to be a viable workaround. When you need to dismiss the whole stack, execute this code in A:
viewControllerB.view.isHidden = true
viewControllerC.dismiss(animated: true) // or viewControllerB.dismiss(animated:true) - it should produce the same result: dismiss viewControllerC
dismiss(animated: false) // dismisses viewControllerB
This should result with the expected behavior.
I am guessing that your segue from A to B is modal as well? In that case the dismiss function called from A wants to dismiss the view, which is immediately on top of A, which is B. C just gets hidden in order to show you the animated hiding of B. In that sense you cannot stack views via modal segues and dismiss the top one with the dismiss function as you described if you go that far back. The dismiss would work as intended if called from B to dismiss C though.
Related
I have a modal view on top of a navigation controller.
I wish to destroy the whole stack and re-create a new one (reload).
However, when assigning the new one to window.rootViewController, warnings appears during runtime and view controllers are not deallocated.
To make things more complicated, I am auto navigating to the modal view controller 'automatically' upon reload, and that < iOS 12 and iOS 13 behaves differently.
I have attached a reprex that demonstrates the issues that will appear. E.g. if you run it as is, on iOS 13, you will see the counter jump from 1 to 3, while on iOS 12, it jumps from 1 to 2. Both are leaking memory (some or all view controllers are not being unloaded).
The main issue is that regardless of how you replace the view hierarchy, your presented VC will dismiss which will send a viewWillAppear message to your "pushedVC" ... at which point "pushedVC" will immediately load and re-present "triggerVC"
What you probably want to do is:
Leave jumpToModalVC equal to false, until you want to use it
On button tap in presented "triggerVC", dismiss the modal (self)
on completion of the dismiss, set jumpToModalVC to true and rebuild / reset your hierarchy
Note:
Chained calls to segues from each VC's viewWillAppear almost always leads to:
Unbalanced calls to begin/end appearance transitions
To avoid that, it's best to trigger the segues from viewDidAppear
If you want, you can add me as a "Collaborator" on your GitHub repo (my GitHub user ID is DonMag), and I can push the changes I made as a new branch.
This is a common problem and for everybody who still doesn't know the correct way how to deal with that, here is the scenario.
Modally presented view controllers A -> B -> C
Now you want to dismiss C with B at one smooth animation landing to view controller A. So apple documentation says that you only need to perform:
[A dismissViewConttollerAnimated:YES completion:nil];
And C with B should be nicely gone. This is really often needed scenario and I'm really said and disappointed that the common use case is not working properly. Why the top view controller C disappears in a moment and B view controller appears with dismissing animation instead of C to be visible for the whole animation process? I would really except to see only C view controller's dismission.
The best solution to use in this case is Unwind Segue. You can directly move switch to any view controller in the heirarchy.
The dismissal of B can't be done in parallel with dismissal of C. This happens sometimes in iOS when the two animations are related somehow - I don't know the exact details.
If you put a breakpoint in C's dismissal completion block, you'll probably see the finished parameter being false, indicating C's animation has been interrupted.
I think the correct solution is to dismiss B only. C will be gone automatically since it was presented by B.
From an initial ViewController I've modally presented a second ViewController using a ShowDetail segue in the storyboard and a performSegueWithIdentifier: method call. The problem is when I dismiss this modal ViewController with the method dismissViewControllerAnimated: the initial ViewController is reinstantiated calling the viewDidLoad again.
I've tried using a Push segue instead of the Show Detail and the initial ViewController keeps allocated in the background as it should.
What might be going on? The initial ViewController never even calls the memory warning method.
Have you tried unwindSegues?
***** Long explanation ahead, skip to solution if you want the quick way *****
First of all, if it is a ShowDetail, it is not a modal view. Do try to see which is your case.
Modal segues can carry information backwards, but are a bit more complicated than push ones.
If you are modally presenting it, you should use Present Modally instead of a ShowDetail.
A modal presentation will always take the top view position in the stack, and Show Detail does as well, depending in how your views are set. For instance, if you have a detail view in stack, IT will be replaced rather than the stack top view.
Try choosing up to a specific segue, I particularly recommend modal assuming you need more than simple pushes (Or the Show would have closed the problem, being the equivalent to the previous deprecated push. If you only need something simple, Show is the way)
Now we've cleared this, what probably is happening is that the view is being removes since Show Detail replaces views instead of pushing them, and it has to perform init again.
***** Solution: *****
The solution then should be not to lose the view when replacing, and reinitializing it, what dismissViewControllerAnimated: does. If you use unwind segues, though, the view should be replaced BUT retained by ARC.
The following link has the best explanation all over the net about how to use it:
What are Unwind segues for and how do you use them?
I am making an iOS app where I want to present a flow of pages like this:
Basically I want to achieve is to have this flow of pages:
PageA
PageB
PageC
PageD, dismiss back to:
PageC
PageD
PageE, dismiss back to:
PageA (starting point, start over again)
I am using ShowViewcontroller to present the pages (modal) and DismissViewcontroller to dismiss.
As per Apple's documentation if I dismiss a VC early in the stack all subsequent UIViewCOntroller are dismissed too (Apple doc).
However I experience that ViewWillAppear and ViewDidAppear are fired on the UIViewController that are dismissed even when they do not appear (e.g. in the example when dismissing back to PageA from PageE then ViewWillAppear is called on PageD, PageC, PageB too).
This does not seem logical to me. Can anyone explain why this is happening? And perhaps correct me if I am approaching this the wrong way.
I am using Xamarin.iOS.
Apple doc:
If you present several view controllers in succession, thus building a stack of presented view controllers, calling this method on a view controller lower in the stack dismisses its immediate child view controller and all view controllers above that child on the stack. When this happens, only the top-most view is dismissed in an animated fashion; any intermediate view controllers are simply removed from the stack. The top-most view is dismissed using its modal transition style, which may differ from the styles used by other view controllers lower in the stack.
The ViewControllers work with a stack. Whenever a new ViewController (of any type) is added to the stack, You lose more and more control of your ViewControllers (especially when using a modal for your ViewControllers). So, say you have 5 ViewControllers in your stack (A, B, C, D, E, as per your example), and assume they are created in the order as stated, in order to return from ViewController E to ViewController A, you'd have to go through the entire stack. That means that every ViewController in your way needs to be displayed first, in order to dismiss is (since you already have ViewController E displayed, this doesn't occur here).
I hope this helps you. Good luck!
Love and regards,
Björn
What is the difference beetween calling presentModalViewController and pushViewController, when :
animation is set to NO (even if yes, that's just an animation style that can be changed).
a navigation controller is defined when presenting the modal view, so it can be navigable too, with a call stack, ....
Is this just to be able to go back from the first pushed view ? Woooaaaaaa.....
I guess the difference is elsewhere and deeper. No ?
Ignoring transitions/animations and how things are structured behind the scenes (which aleph_null's alswer provides a good discussion of), the only user-facing difference is the ability to return to the preceding view automatically using the navigation bar.
If you use pushViewController you will automatically get a "Back" button in the navigation bar. If you use presentModalViewController you do not, and generally will have to implement your own controls and/or callbacks to handle dismissing the controller.
Conceptually the modal presentation style is generally used for atomic tasks that you cannot navigate away from (i.e. you either complete the task, or you cancel, and you cannot do anything else within the app until you do one or the other).
If you're wondering why have the difference in the first place, I can't say. Personally I think frameworks that provide a unified API for moving from one controller to another (like cocos2d, or Android) make a lot more sense.
The most important difference is about semantics. Modal view controllers typically indicate that the user has to provide some information or do something. This link explains it more in depth: http://developer.apple.com/library/ios/#featuredarticles/ViewControllerPGforiPhoneOS/ModalViewControllers/ModalViewControllers.html
Here's another, less abstract difference they talk about:
"When you present a modal view controller, the system creates a parent-child relationship between the view controller that did the presenting and the view controller that was presented. Specifically, the view controller that did the presenting updates its modalViewController property to point to its presented (child) view controller. Similarly, the presented view controller updates its parentViewController property to point back to the view controller that presented it."
Also see this thread: why "present modal view controller"?
Take a look into the viewControllers in the image
The top 2 viewControllers(login & submit) at the top left are disconnected from the tabBarController & NavigationController
The rest of the viewControllers are embedded in a NavigationController. They somehow belong to the natural flow of the app.
Now you have to ask yourself
Do I need to always show login + submit page every time? It would be pain in the neck for the user to each time go to login even if they logged in last time. These 2 screen really don't fit the natural flow of the screens. So what do we do? We just add them modally using presentViewController
However for the rest of the viewControllers we want to keep them inside 2 navigation so we can easily go back and forth so we use pushViewController
For more information I recommend you to see this video
The image was also picked from this great answer. It's worthy of a look.
This is what my experience says,if you want to manage a hierarchy of views,better go for pushViewController in the navigation controller. It works like a stack of view-controllers in the navigation controller. If however the requirement is just to show a view on executing some actions on the parent view controller then the best way is presenting it modally.
If you need a complex push pop logic always prefer a pushViewController.
UINavigationController are used when you want to have some sort of hierarchal representation of your data (ie drill down). They work using a stack of UIViewController subclasses. Every time you “drill down”, you simply add another view controller to the stack. Then, the “back” logic is simply a matter of popping view controllers off of a stack.
You can check out this link:
http://www.icodeblog.com/2011/10/11/back-to-basics-an-introduction-to-view-controllers/