I want to change position of UIPopover after the view is rotated. can you tell me what method is called after view is rotated so that I can get the coordinates of UI elments in the final view rendered after rotation of view
popover behavior in any Apples native application. You'll see that in response to device rotation popover should disappear before rotation animation and appear again on new appropriate place after it ends. So you should dismiss your popover and then popup it on new place with new coordinates (how to get these coordinates)
Thanx in advance
From the docs for -[UIViewController didRotateFromInterfaceOrientation:]:
Sent to the view controller after the user interface rotates. … Subclasses may override this method to perform additional actions immediately after the rotation. … By the time this method is called, the interfaceOrientation property is already set to the new orientation.
Related
I am presenting UINavigationController with modalPresentationStyle=UIModalPresentationFormSheet on iPad with iOS 8 . In the root view controller, I need to find the moment when the screen rotation is performed, but I am not receiving any events that I'm expecting:
-didRotateFromInterfaceOrientation: is deprecated and not called
The new -viewWillTransitionToSize:withTransitionCoordinator: and -traitCollectionDidChange: are not called because view seems to not transform in size.
-application:didChangeStatusBarOrientation: is called too early, not at the end of the rotation.
How can I find the moment of rotation end?
I am presenting a modal view (with UIModalPresentationFormSheet) on top of a UISplitViewController. I want to get the exact rect that the modal view will take relative to the UISplitViewController (which is basically the whole window). i.e. the modal view is at x,y coordinate and the size.
How would I find this? I looked at UIView's "convertRect:fromView:" method, but couldn't figure out what combination would work.
Thanks.
[splitView convertRect:modallyPresentedVC.view.bounds fromView:modallyPresentedVC.view] should do the trick. Make sure to call it in the completion block of the presentation (after all animation has finished).
My app has four tabs: A, B, C and D. Their UIViewController are managed by UITabBarController. The app supports rotation, and so each view controller returns YES to shouldAutorotateToInterfaceOrientation.
Using springs and struts, most of the rotation is done automatically by iOS. However, tab A also requires further positioning, and it is done in its VC's willRotateToInterfaceOrientation method.
When the VC for tab A is selected and the screen is rotated, that VC receives a willRotateToInterfaceOrientation message (propagated by iOS from UITabBarController), and the resulting rotation is correct.
However, when the selected tab is B and the screen is rotated, A's willRotateToInterfaceOrientation is not called. Makes sense. But if I then select tab A, I get only the results of applying its springs and struts, without the post-processing done by its willRotateToInterfaceOrientation.
After struggling with this for a while, and after failing to find a solution online, I came up with the following. I subclassed UITabBarController and in its willRotateToInterfaceOrientation I call all the VCs' willRotateToInterfaceOrientation regardless of which one is the selectedViewController:
- (void) willRotateToInterfaceOrientation:(UIInterfaceOrientation)toInterfaceOrientation duration:(NSTimeInterval)duration {
if (self.viewControllers != nil) {
for (UIViewController *v in self.viewControllers)
[v willRotateToInterfaceOrientation:toInterfaceOrientation duration:duration];
}
}
It works, but it looks like a hack, and my question is whether I was doing the right thing. Is there a way to tell iOS to always call a VC's willRotateToInterfaceOrientation before displaying it for the first time after a screen rotation?
The best way to handle custom layout is by subclassing UIView and overriding the layoutSubviews method. The system sends layoutSubviews to a view whenever its size is changed (and at other times). So when your view A is about to appear on screen with a different size (because the interface was rotated while view B was on screen), the system sends view A a layoutSubviews message, even though it doesn't send view controller A a willRotateToInterfaceOrientation: message.
If you are targeting iOS 5.0 or later, you can override the viewDidLayoutSubviews method of your UIViewController subclass and do your layout there, instead of subclassing UIView. I prefer to do it in my view's layoutSubviews, to keep my view-specific logic separate from my control logic.
It's also a bad idea to do layout in willRotateToInterfaceOrientation: because the system sends that message before actually changing the size of the view, and before the rotation animation block. It sends the willAnimateRotationToInterfaceOrientation:duration:, layoutSubviews, and viewDidLayoutSubviews messages inside the rotation animation block, so the repositioning of your subviews will be animated if the view is on screen during the rotation.
I am trying to track down a problem where the viewWillLayoutSubviews (and viewDidLayoutSubviews) method do not get called after dismising a controller displayed using -
[self presentModalViewController:controller animated:YES];
and dismissing with
[self dismissModalViewControllerAnimated:YES];.
This view controller is displayed on top of a UISplitViewController as the result of a button being pressed in the detail area. When I rotate the device, without the modal up, I do get the viewWillLayoutSubviews callback. However, the problem is, when I rotate during the presentation of the model, it does not update the views correctly and recalculate the view bounds after dismissing it. According to the IOS 5 release notes I should get a viewDidLayoutSubviews after dismissing the modal view controller.
For comparison, I created a bare bones app with none of my other code in it and it works as documented, it will call viewWillLayoutSubviews after the modal is dismissed.
I have been going over and over my real app code and can't find anything wrong. I am looking for suggestions for things to do help figure this out. Why would the callback work when rotating but not work when the modal is dismissed? Could it be something with my view hierarchy?
Thanks for any help!
Try using the delegate method viewWillAppear instead of viewWillLayoutSubviews. The WillLayoutSubviews is only called when the view's bounds change (which happens when you rotate the device).
I'm doing some fancy stuff with rotation, and am returning NO from shouldAutorotateToInterfaceOrientation:. I then manually rotate a UIWebView according to [UIDevice currentDevice].orientationCached. When I hold my finger down on a link, the menu which appears is always in PortraitLeft orientation, no matter how the device is actually oriented, and no matter how the UIWebView is oriented.
It looks to me like the link menu takes its orientation from the main view of the view controller, rather than the UIWebView its associated with, and that the only way to get it to behave correctly is to return YES from -shouldAutorotateToInterfaceOrientation:.
Is this assumption correct? Is there any way to control the orientation of the link-related popup menu, or to force it to take its orientation from the UIWebView which spawns it?
I wouldn't actually set the orientation manually how you're doing it in the UIWebView. Instead, force the orientation of the parent view controller through code.
As an example of a similar situation, I have an app that I've developed that displays a map in a few views. When rotated from portrait to landscape, it layouts the view in a very different manner from the portrait layout with a fancy animation. I like it, but some users don't, so I provide the option to disable map rotation. And I do that by passing in only certain rotation abilities to the parent view. So if they disable landscape, I tell the parent view controller it can only rotate to landscape. Otherwise, it's free to rotate to any orientation except upside down.
Enough with the explanation: here's my relevant code I use to accomplish this:
- (BOOL)shouldAutorotateToInterfaceOrientation:(UIInterfaceOrientation)toInterfaceOrientation {
//Rotate the view if rotation is actually enabled
if ([self.prefs boolForKey:#"SHOULD_ROTATE"]) {
return (UIInterfaceOrientationIsLandscape(toInterfaceOrientation) || UIInterfaceOrientationPortrait == toInterfaceOrientation);
}
//Rotate it to portrait only if rotation is disabled
else if (![self.prefs boolForKey:#"SHOULD_ROTATE"]) {
return (UIInterfaceOrientationPortrait == toInterfaceOrientation);
}
//Otherwise, rotate only to portrait (for all views minus the map views)
else {
return (UIInterfaceOrientationPortrait == toInterfaceOrientation);
}
}
I actually implement this in the UITabBarController so that it applies to all views and view controllers in the app, but it's just as easily implemented only for the UIWebView parent view controller. The gist is that you're returning yes or no based on if the view orientation matches what you want it to. For the web view, you would want to lay out the only allowed rotation orientations to by returning this:
return (UIInterfaceOrientationIsLandscape(toInterfaceOrientation)
Of course, I haven't discussed forcing the view to set the view to a landscape view, only what it does once a user turns it. So the best course of action there is simply to manually do it once the view is initialized:
[[UIApplication sharedApplication] setStatusBarOrientation:UIDeviceOrientationLandscapeLeft animated:NO]
You'll have to set it to either Left or Right to start with, but the user can rotate between right and left as they wish if you implement my earlier code as well.
That's a lot of explanation, but I think the combination of these two methods for the parent view controller should allow you to present the view exactly how you wish. Let me know if you have any questions!
By "popup menu", do you mean the Action Sheet with Open … Copy buttons?
If so, then yes, Action Sheet always presents itself according to the top view controller's interfaceOrientation. Because you are rotating the view yourself without its controller updating its interfaceOrientation, the Action Sheet still thinks it is portrait.