I have a UIViewController that returns YES
in shouldAutorotateToInterfaceOrientation:
for UIDeviceOrientationPortrait
and NO
for everything else. With that view on the top of the stack, I use pushViewController:animated:
to push a new UIViewController
. The new controller returns YES
for anything in shouldAutorotateToInterfaceOrientation:
.
The first view refuses to rotate (as expected). Once the second view is pushed, the user can rotate the device and the UI will rotate (also as expected). If the second view is in landscape mode and the user presses the back button (which calls popViewControllerAnimated:
), the first view will appear rotated (unexpected!).
If the user rotates the device back to portrait orientation, the view will rotate and then be stuck in portrait mode as before. This works but it's ugly for the user until they rotate back. So I'm in search of a way to make this view stay in portrait mode.
The only workaround I have found so far is to use -[UIDevice setOrientation:]
, which throws a warning (orientation
is read-only) but works since it is actually defined. This is a huge hack and I'd like a real solution. In search of a real solution I attached GDB to the Photos application (MobileSlideshow.app) and discovered that it too uses -[UIDevice setOrientation:]
. Being an internal application though I guess they have different rules.
Is there a correct way to achieve the expected autorotation behavior?
iOS 5 adds +[UIViewController attemptRotationToDeviceOrientation], which solves the problem for me.
Try it again with the 3.0 OS (now that we can talk about it). Two special cases of this have been worked out under 3.0:
Presenting a portrait modal view over a landscape view and vice-versa. An example is the pre-3.0 behaviour in Mail for viewing attachments. You could rotate to landscape for a PDF and get back the portrait view for the message when you dismissed the attachment view. (Now that we have landscape message view in 3.0 this behaviour seems to be gone).
Mixing orientations within a view stack and getting the correct orientation back when you pop the stack. An example is the transition between the tableview of movies and the movie view in the YouTube app.
There seem to have been some thorny aesthetic problems of how the default transitions for all the permutations should look. There are some weird elements if you view in slo-mo, but it beats bending over backwards in your own code.
I found a nice workaround for this problem. The clue is to support all orientations for all views in
UINavigationController
.I've got 2 views in controller. Root view is to support only
LandscapeRight
, and second supports bothLandscapeRight
andPortrait
.Second view
shouldAutorotateToInterfaceOrientation
method looks as usual:The workaround itself is contained in Root view source Now the root view rotates in terms of code, but the user cant see it.
So this annoying bug comes a really long way from iOS 1 to iOS 4.
I believe the best solution we have it duplicate this bug and let Apple know we really want it fixed. I've just reported it again under the bug ID 8478525.
It has been a old post but since it hasn't been solved. I would like to share my solution, for any others who might be in a headache.
Objective: A UINavigationController and most of viewcontrollers in its stack fixed at portrait, except for one viewcontroller in the stack being allowed to rotate to both portrait and landscape.
Problem: intuitively I set an selective shouldAutorotateToInterfaceOrientation by checking if the topViewController is the rotableViewController. However after poping back from the rotableViewController at the landscape mode, the navigationcontroller is now shown in the landscape mode although it is not allowed.
Solution:The killer is to disallow the rotation at
viewWillAppear
and present & dismiss a modalViewController without animation.I was about to tell you that there was probably no way, but then I had a thought. It would be difficult to get right, but you might be able to make it work if you used two separate
UINavigationController
s: one that controls the root view and prohibits rotation, and one for the child views that allows it. You would manually handle the transition to and from the root controller and the child controller.You'd have to patch up the child navigation controller to have the correct back button. And, of course, you'd have to handle the back button press yourself. You would probably have to use a dummy
UINavigationBar
to do the animation from one navigation controller to the next so that the transition will look right. You would also have to animate the "push" transition between the navigation controllers, as well, which might take a bit of tweaking to get it to look right. You would have to:UINavigationItem
and push it on)UINavigationItem
for the incoming view controller and push it on the dummy navigation barUINavigationBar
from the view, and also the outgoing navigation controller.All of this is a lot of work, but if you're very clever (and very tenacious), you might be able to get it to work. I'd love to see the result!
That said, you might be better off just using
setOrientation:
and taking your chances with the App Store approval process ;-)