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
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 want to return to the previous/root view controller after a certain method finish running. I have found code that could work but I'm not using a navigation controller. I have tried Programmatically changing View Controllers without Navigation Controller Swift but I am not sure how to code it in obj-c. Please help!
Thanks in advance!
If you have presented your view controller (not embeded in a container) than you can simply call
[self dismissViewControllerAnimated:YES/NO completion:nil];
at the end of your certain method.
This turns out from the View Controller Programming Guide for iOS
To dismiss a presented view controller, call the
dismissViewControllerAnimated:completion: method of the presenting
view controller. You can also call this method on the presented view
controller itself. When you call the method on the presented view
controller, UIKit automatically forwards the request to the presenting
view controller.
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.
I have a UIViewController that's embedded in a Navigation View Controller. I then modally present another view controller that shows a countdown. Once the countdown ends, the modal view controller should be dismissed and show a different underlying view controller from the original presenting UIViewController.
Does anyone know how to do this in ios8 with Swift?
There are different ways to approach this. One way is to replace the initial presenting view controller with the desired underlying one when you present the modal view controller.
NSArray * viewControllers = [self.navigationController viewControllers];
[viewControllers replaceObjectAtIndex:viewControllers.count - 1 withObject:replacementController];
Dismissing the modal will simply show the different underlying view controller that was already swapped.
when you do popViewController from stack there is a handler. This will be called at the end of this function so you can pass a block where you can presentViewController or make change to the current one.
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".