iOS documentation for dismissViewControllerAnimated:completion: states:
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.
This means when dismissing two modal view controllers at once using
[[[self presentingViewController] presentingViewController] dismissViewControllerAnimated:YES completion:nil];
the animation shown should be the top modal view being dismissed.
This is indeed the case in iOS 7 and prior, but in iOS 8 the animation shown is not the top-most view (in my experience, it's the second top-most view). Is this behavior a bug in iOS 8 or am I doing something wrong?
As commented above: I see the exact same issue in an unwind segue context. I just toke the workaround as described here using a screenshot and add it as a subview to all intermediate viewControllers: How to dismiss a stack of modal view controllers with animation without flashing on screen any of the presented VCs between the top and bottom?
// this in during unwind in a custom UIStoryboardSegue (that is the reason why it might look wrong with what is what: srcViewController and destViewController
UIViewController* aPresentedViewController = destViewController.presentedViewController;
while (aPresentedViewController != nil) {
if (aPresentedViewController == srcViewController) {
break;
}
UIView *anotherSrcViewCopy = [srcViewController.view snapshotViewAfterScreenUpdates: NO];
anotherSrcViewCopy.autoresizingMask = UIViewAutoresizingFlexibleHeight | UIViewAutoresizingFlexibleWidth;
[aPresentedViewController.view addSubview:anotherSrcViewCopy];
// recurse through the presentedViewController hierarchy
aPresentedViewController = aPresentedViewController.presentedViewController;
}
Same problem and same solution here than #theguy.
Here's my version in Swift without iterating on all the view controllers :
guard
let presentedViewController = segue.destination.presentedViewController,
let viewToCopy = segue.source.view.snapshotView(afterScreenUpdates: false)
else { return }
viewToCopy.autoresizingMask = [.flexibleWidth, .flexibleHeight]
presentedViewController.view.addSubview(viewToCopy)
Related
I'm writing a custom segue class (HySegue) which allows views to animate the transition. The code is working great, except when under a UINavigationController stack. Actually, the transitions run and animate well, but the top UINavigationBar is what is causing me problems.
When first animating, I add the destination view as a subview of the source view. As such:
UIView * sourceView = sourceViewController.view;
UIView * destinationView = viewControllerToPresent.view;
// Force the source view to layout
[sourceView addSubview:destinationView];
[sourceView layoutIfNeeded];
When the transition is over, I present the destination view controller:
UIViewController * parentViewController = viewControllerToDismiss.parentViewController;
UIView * destinationView = destinationViewController.view;
// Break the view hierarchy that was setup earlier
[destinationView removeFromSuperview];
// When presenting in a UINavigationController stack, push the destination view controller
if ([parentViewController isKindOfClass:[UINavigationController class]]) {
[(UINavigationController *)parentViewController pushViewController:destinationViewController
animated:NO];
}
else {
// Present the destination view controller
[viewControllerToDismiss presentViewController:destinationViewController
animated:NO
completion:nil];
[viewControllerToDismiss willMoveToParentViewController:nil];
[viewControllerToDismiss.view removeFromSuperview];
[viewControllerToDismiss removeFromParentViewController];
[viewControllerToDismiss didMoveToParentViewController:nil];
}
The problem is that during the animation the destination view does not know that it's being pushed in a navigation stack and so the top bar, although visible, is not taken into account in the view's bounds. That is, the navigation bar is visible because it's visible for the source view controller, but the destination view controller knows nothing about it. When the animation finishes the destination view controller is pushed onto the stack, so it now knows about the navigation bar, and all my content with Top Space to Top Layout Guides constraints jumps down on the frame.
The top bar also doesn't show in IB. This is when I use my custom segue:
And this is when I use show segue:
Notice that the bar shows on the later but not on the former.
What I was wondering is how IB knows that it's a push segue. Is it some flag? Is it because of the specific class it's using? How would I make my custom segue also a push segue?
Edit: I loved the segue's type in prepareForSegue:sender: and it seems its type is UIStoryboardPushSegue, which is not a public or documented class. How can I can I solve it then? I already tried setting the destination view's frame and bounds from the source view.
I have a view controller presented using UIModalPresentationCustom presentation style. I use a custom UIViewControllerTransitioningDelegate to present the view controller as a sidebar (so it slides in from the edge of the screen and does not occupy the full screen).
However when I then present another view controller from this one using UIModalPresentationFullScreen — and then dismiss the full screen view controller, my underlying custom presented controller is suddenly resized to occupy the full screen. Does anyone know why this is the case?
Edit: this is essentially my animateTransition method for presenting the sidebar — I've stripped out most of the code to make it readable. Basically it gets the container from the transitionContext, adds and animates the destination view controller's view to the container.
- (void)animateTransition:(id<UIViewControllerContextTransitioning>)transitionContext
{
UIView *container = transitionContext.containerView;
UIViewController *fromVC = [transitionContext viewControllerForKey:UITransitionContextFromViewControllerKey];
UIViewController *toVC = [transitionContext viewControllerForKey:UITransitionContextToViewControllerKey];
UIView *fromView = fromVC.view;
UIView *toView = toVC.view;
if( toVC.isBeingPresented )
{
[container addSubview:toView];
//... Animate some new frame for toView
//Call [transitionContext completeTransition:YES] on animation completion
}
else
{
//... Animate fromView out
//On completion remove fromView from superview
//Call [transitionContext completeTransition:YES] on animation completion
}
}
Edit 2: Doing a little more research, I notice that the frame of my custom presented view controller's view is being set when the view controller above it in the modal stack is dismissed. The following stack trace leads to the frame being set as full screen:
0 -[MyCustomPresentedViewControllerView setFrame:]
1 -[UIView(MPAdditions) setFrameOrigin:]
2 -[UIViewControllerAccessibility(SafeCategory) dismissViewControllerWithTransition:completion:]
3 -[UIViewController dismissViewControllerAnimated:completion:]
Changing the presentation style by assigning:
viewController.modalPresentationStyle = UIModalPresentationOverCurrentContext;
results in the modal presentation controller occupying a fraction of the screen, the same fraction as the original presented view controller of the UIPresentationController.
However, using viewController.modalPresentationStyle = UIModalPresentationOverFullScreen
is better for this case, since his modal controller is full screen.
I am experiencing the same issue. I've tried debugging it using symbolic breakpoints and there seem to be some internal call on some kind of layout manager that does this.
While I wasn't able to "solve" this (it seems to me like a bug in the SDK), I was able to come up with a workaround that fixes this. Basically, you have to set the correct dimensions of the presented view at two opportune times. Like this:
In the view controller that was presented using your custom UIPresentationController, add this:
- (void)viewWillAppear:(BOOL)animated {
[super viewWillAppear:animated];
dispatch_async(dispatch_get_main_queue(), ^{
self.view.frame = [self.presentationController frameOfPresentedViewInContainerView];
});
}
- (void)viewDidAppear:(BOOL)animated {
[super viewDidAppear:animated];
self.view.frame = [self.presentationController frameOfPresentedViewInContainerView];
}
And if you are wondering: yes, you do need it to do in two places. Because weirdly enough, when I did it only in the viewDidAppear async block, it got broken (resized to fullscreen) once the animation finished.
Try to use:
viewController.modalPresentationStyle = UIModalPresentationOverCurrentContext;
It helped me in iOS 8.1
I have been following a solution on this question in order to display a view with a transparent background. The issue that I'm having is once the modal view controller has been displayed, the underlying view doesn't get rotated anymore.
For example if A is my view controller, then B is my modal view. The issue is as follows. I currently have my device in portrait and have A displayed. I then present B modally. I then rotate my device and B rotates with it, however A stays as it was.
Please could someone advise on how to handle this rotation so that the underlying view (A) gets rotated too?
ModalViewController is used to interrupt the current workflow and displaying a new set of views. So when you present modally, here in this case you are presenting B, the current active Viewcontroller is B and not A.
A ViewController is traditional controller objects in the Model-View-Controller (MVC) design pattern. They also take care of user interface, gesture recognitions,event management(of buttons for example) and the alignment of views in present in them.
When you presented B, the current viewcontroller changed from A to B and hence when you try to rotate(if the orientation support is provided) the view of B is effected as its the viewcontroller active and it responds to the rotation. Normally we go unnoticed these because the view is opaque. Here in your case the view is transparent and we notice that A has not responded to rotation.
I tried the above example in iOS6 (from the one you mentioned)
ViewController2 *vc = [self.storyboard instantiateViewControllerWithIdentifier:#"VC2"];
vc.view.backgroundColor = [UIColor clearColor];
self.modalPresentationStyle = UIModalPresentationCurrentContext;
[self presentViewController:vc animated:YES completion:nil];
here A remained in portrait mode
When i did this adding the second viewcontroller's view as a subview, A changed to landscape
ViewController2 *vc = [self.storyboard instantiateViewControllerWithIdentifier:#"VC2"];
vc.view.backgroundColor = [UIColor clearColor];
self.view addSubview:vc.view];
this happend because in the second trial the active viewcontroller was A and not B as B's view was a subview added to A. Go through Apples's Document on
About ViewController
About windows and views
Presenting ViewControllers
I have an UIViewController(called MainViewController) which presents modally a semi-transparent view (HelpOverlayViewController):
HelpOverlayViewController *helpOverlayViewController = [[HelpOverlayViewController alloc] init];
self.modalPresentationStyle = UIModalPresentationCurrentContext;
helpOverlayViewController.modalTransitionStyle = UIModalTransitionStyleCrossDissolve;
[self presentViewController:helpOverlayViewController animated:YES completion:nil];
If the user rotates the device while the HelpOverlayViewController is shown it only rotates HelpOverlayViewController and not the MainViewController i.e. the parent controller. This is a problem since HelpOverlayViewController is semi-transparent and MainViewController is visible below it.
Both controllers have the method
- (BOOL)shouldAutorotateToInterfaceOrientation:(UIInterfaceOrientation)interfaceOrientation
{
return YES;
}
They both rotate fine independently.
Is there some way I can force the underlaying view controller to rotate when the modal view does?
I do know that issues like this will likely be largely resolved with iOS 6 as it has a different model for handling rotations.
However, that doesn't help you now. You might be best off just making your HelpOverlay a UIView and not a UIViewController. You can add this semi-transparent view onto the top of your MainViewController (or any other). You can still create an animation (like a fade-in) when adding this subview to your view hierarchy. With this model, you'll no longer have any issues with rotations.
I'm trying to make a custom segue so that the destination view controller slides down from the top.
I wrote my code according to the example from the documentation.
The problem is that when the segue is executed, the source view controller goes black, and then the animation occurs. How can I prevent the source view controller from going black?
(I already tried implementing the solution presented in this answer but the screen either goes black after the transition, or reverts to the source view controller.)
Here's my code:
-(void)perform{
UIViewController *splashScreen = self.sourceViewController;
UIViewController *mainScreen = self.destinationViewController;
//Place the destination VC above the visible area
mainScreen.view.center = CGPointMake(mainScreen.view.center.x,
mainScreen.view.center.y-600);
//Animation to move the VC down into the visible area
[UIView animateWithDuration:1
animations:^{
mainScreen.view.center = CGPointMake(mainScreen.view.center.x, [[UIScreen mainScreen] bounds].size.height/2 );
}
];
[splashScreen presentModalViewController:mainScreen animated:NO];
}
The reason that your source view controller seems to be hidden is that the destination view controller is presented right away.
When you are writing custom segues you don't have both views available at the same time. You could either
push view controller, add the source view to the destination view controller and animate
add the destination view to the source view controller and animate, then push view controller
push to an in-between view controller, add both views, animate, push to the destination view controller.
In all the above cases where I say push view controllers you could instead present view controllers modally. In fact that might be more suitable for the in-between view controller solution.