What happens with presenting viewController after it presents a presented viewController. Does its instance live forward? Is it destroyed when it is obscured by presented viewController views? If it is destroyed, how do I tell the system not to destroy it, but keep it intact?
I'm designing a game in witch the game is obscured with a presented viewController when some button is clicked. When the player returns to the game, I want it to restore its state exactly as it was before presenting a viewController
The presenting view controller keeps it's instance, and control is returned to it after the presented view controller is dismissed. In fact, you should have the presenting view controller dismiss the presented controller if possible.
Since the instance of UIViewControllers stay intact when presenting (or pushing) another view controller, it is best practice to implement the didReceiveMemoryWarning method in your UIViewControllers to release any memory that you can (clear caches, etc). Any data you clear out you may want to re-populate in the viewWillAppear method.
Other info from the View Controller Programming Guide for iOS :
Support for presenting view controllers is built in to the UIViewController class and is available to all view controller objects. You can present any view controller from any other view controller, although UIKit might reroute the request to a different view controller. Presenting a view controller creates a relationship between the original view controller, known as the presenting view controller, and the new view controller to be displayed, known as the presented view controller. This relationship forms part of the view controller hierarchy and remains in place until the presented view controller is dismissed.
Related
I am trying to achieve a navigation similar to the Netflix app for iOS. When you click on a movie, a modal window pops up with a close button. If within this movie I choose to see another movie then the second modal pops up and in addition to the close button, a back button appears. I can use the back button to dismiss one by one and the close button to return to the base screen.
I am able to dismiss a single view using
dismiss(animated: true, completion: nil)
but how can I return to the base screen closing all modals at once? Also, is modals the way to go? I chose this because I didn't want the navigation bar on top.
I'm working with Swift 4.2 in Xcode 10.
The way you are dismissing a ViewController is not the correct way. The presenting view controller is responsible for dismissing the view controller. Ideally you have to implement a protocol in your presenting ViewController and , dismiss your modal from your 'presenting' ViewController not 'presented' ViewController.
The reason why your way still works is, when a ViewController calls self.dimiss if there's nothing to dismiss UIKit will delegate it back to its parent. If you implement this correct way, once you dismiss , your presenting viewcontroller will dismiss , hence all the presented viewcontrollers will be dismissed instead of the last one.
From Apple Docs:
The presenting view controller is responsible for dismissing the view controller it presented. If you call this method on the presented view controller itself, UIKit asks the presenting view controller to handle the dismissal.
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.
If you want to retain a reference to the view controller's presented view controller, get the value in the presentedViewController property before calling this method.
The completion handler is called after the viewDidDisappear(_:) method is called on the presented view controller.
try this
self.navigationController?.viewControllers.removeAll(where: {$0.isModalInPopover})
I wanted to ask who should be the one dismissing a presented view controller?
Lets say I presented a view controller and on an IBAction in that view controller, I want to dismiss it.
Should I be passing that responsibility to the presenting view controller by creating a delegate method or I should be just calling the dismissViewController:animated: on itself, which inturn anyways asks its presenting view controller to dismiss the presented view controller?
So, I think these are some clear cut cases where the presenting view controller should be the one dismissing the presented view controller
The presented view controller is passing some data back to the presenting view controller.
The presenting view controller wants to do something after the dismissal of the presented view controller.
The presenting view controller to handle how the dismissal is going to happen, does it need some kind of animation
What if the presented view controller first checks if the presenting view controller actually wants to take the responsibility of dismissal by checking the presenting view controller implemented the dismissal delegate method?
Is it really worth putting the complexity of conditional logic here?
And yes, I tried reading it on other forums and questions like
Dismissing a Presented View Controller
Dismissing Modal View Controllers
Present and dismiss modal view controller
view controllers: presentation, dismissal
But couldn't really find the right logical answer.
Read this below link. You will get the idea how animation and presentation take place between viewcontrollers.
https://www.raywenderlich.com/113845/ios-animation-tutorial-custom-view-controller-presentation-transitions
I am presenting a view controller like this:
UINavigationController * PlacesNC = [storyboard instantiateViewControllerWithIdentifier:#"PlacesNavigationController"];
[self presentViewController:PlacesNC animated:YES completion:nil];
Once I am at the final view controller that is presented using the navigation view controller, how can I remove the initial view controller from memory?
Edit
In my application it is possible to present multiple UIViewControllers in this fashion. I will try to give a representation of what my stack might look like.
____ modal vc 5 * current view controller
____ modal vc 4
____ modal vc 3
____ modal vc 2
____ modal vc 1
____ root view controller
So if I have a stack like this, how can I remove vc 1,2,3 and maybe even 4 so that I can release the memory these other view controllers are using up? This may not be the correct to allow such a stack as this, but this is what I have now, and I just need a temporary fix as the iPhone 4 cannot handle the amount of memory used in a stack like this. So until I can come up with an alternate way to present my view controllers I just need to be able to remove some of them from the stack.
You cannot, and you don't want to. It is still in the view controller hierarchy, as I show in this diagram (DrillViewController is presented, but RootViewController is still there, "behind" it):
Presenting a view controller does not destroy the presented view controller, nor should it; if it did, you would not be able to dismiss the presented view controller and find the presenting view controller still sitting there.
Moreover, in iOS 8 it is perfectly possible to present a view controller and show the presented view controller's view in front of the presenting view controller's view, which remains visible behind it. That, for example, is how a UIAlertController presentation works. Clearly it would be a disaster if the presenting view controller ceased to exist in that situation.
Now, it may be that what you really mean is: My view controller has a property that uses a lot of memory. I don't need to hang on to that when my view controller is not frontmost. So I'd like to release it when I present another view controller. In that case, just manage the memory manually: set that property to nil on viewDidDisappear:, and recover its value (somehow) on viewWillAppear: when the presented view controller is dismissed.
One final suggestion: Perhaps the real problem is that a presented view controller was just the wrong type of hierarchical arrangement to start with. Perhaps what you really want to do is replace your original view controller in the view controller with the new view controller - because you are never coming back to it and don't need it any longer. That is perfectly possible, but of course you'll need to set up a different hierarchy architecture.
I'm reading a book that states that source view controller is not necessarily a presenting view controller. The source VC is the one that calls presentViewController:... method, and the presenting VC(it's view) is the one that gets obscured by a presented VC view. I can't think of a single example in which the presenting VC is not the same as source VC. Please provide some. Thanks
Text from book:
“Original presenter:
The view controller to which presentViewController:animated:completion: was sent. Apple sometimes refers to this view controller as the source; “original presenter” is my own term.
The presented view controller is set as the original presenter’s presentedViewController.
Presenting view controller:
The presented view controller’s presentingViewController. This is the view controller whose view is replaced or covered by the presented view controller’s view. By default, it is the view controller whose view is the entire interface — namely, either the root view controller or an already existing presented view controller. It might not be the same as the original presenter.
The presented view controller is set as the presenting view controller’s presentedViewController. Thus, the presented view controller might be the presentedViewController of two different view controllers.”
I was asking myself the same question when learning about view controller transitions, specifically when trying to understand the animationControllerForPresentedController:presentingController:sourceController: method from the UIViewControllerTransitioningDelegate protocol. The struggle was about the difference between the presentingController and sourceController arguments.
I found the answer in the View Controller Programming Guide. You can find the following in the Presenting View Controllers Modally section:
The view controller that calls the
presentViewController:animated:completion: method may not be the one
that actually performs the modal presentation. The presentation style
determines how that view controller is to be presented, including the
characteristics required of the presenting view controller. For
example, a full-screen presentation must be initiated by a full-screen
view controller. If the current presenting view controller is not
suitable, UIKit walks the view controller hierarchy until it finds one
that is. Upon completion of a modal presentation, UIKit updates the
presentingViewController and presentedViewController properties of the
affected view controllers.
This means that the 'source' view controller concept is not something randomly created by the author of the book you mentioned.
I'm afraid the book you're reading may have made a complex subject even more complex by adding the so-called Source View Controller to the whole mix of names.
For starters, there is no such concept of a "Source" in View Controllers. You have a parentViewController and childViewControllers only when talking about Container View Controllers. And you have a presentingViewController and a presentedViewController only when talking about presenting View Controllers modally.
You also have View Controllers whose main purpose is to manage other View Controllers, namely the Navigation Controller, the Tab Bar Controller, the Split View Controller and the Popover Presentation Controller. So any given View Controller may query itself to know if it is "attached" to a Navigation Controller, for instance.
What I'm guessing your book is implying is that a Source VC would be the one that makes another VC appear on screen. In this sense, it is right. The "source" may be different than the presenting VC. Take this snippet:
[self presentViewController:aViewController animated:YES completion:nil];
In the example above, the presenting VC is also the "source" VC. But here:
[someViewController presentViewController:anotherViewController animated:YES completion:nil];
We are calling the method on some VC lying somewhere passing yet another VC as argument. So in this case the presenting VC is someViewController and the presented VC is anotherViewController. Should this line of code be inside a third VC, then said third VC would be the "source".
But that's the thing! This last snippet of code may not even be inside a View Controller in the first place, so it's a bit odd to think about "source VCs".
Is there a way to know if a UIViewController has been presented and dismissed modally ?
Something like:
hasBeenPresentedModally
hasBeenDismissedModally
thanks
There's nothing built in, but a view controller could, upon receiving viewDidAppear and/or viewWillDisappear check whether it has a parentViewController, since per Apple's documentation (emphasis added):
Parent view controllers are relevant in navigation, tab bar, and modal
view controller hierarchies. In each of these hierarchies, the parent
is the object responsible for displaying the current view controller.
If you are using a view controller as a standalone object—that is, not
as part of a view controller hierarchy—the value in this property is
nil.
If it has then it can set suitable flags for future reference.
Note that being presented modally is different from being truly modal. For example, on an iPad you might put one controller inside a UIPopoverController, so that controller isn't presented modally, but then it might modally present another controller on top of itself. So the second controller is presented modally but isn't itself a modal dialogue because — if the program is otherwise set up suitably — the user can just ignore the popover entirely.
Check if your UIViewController's parentViewController property is nil or not.
If the property is nil then it's dismissed otherwise it's presented.
NOTE: UITableViewController's childViewController's parentViewController property would also be not nil, you should also make sure the parentViewController is not UITableViewController.