views:

959

answers:

3

I have a really strange orientation issue. I have a sequence of view controllers under a navigation controller. One of them can take any orientation. When I'm leaving the orientation I have to use setOrientation. The funny thing is the rotation takes place as the transition occurs to the next page. This isn't normally a problem except for a single case -- from UIDeviceOrientationPortraitUpsideDown to normal causes all my top mounted items to migrate up about an eighth of a page.

There are three ways I think I could fix it:

  1. Somehow separate the setOrientation from my pushViewController call (so the new view doesn't need to flip)
  2. Set my items to be anchored at the top of the device in a better manner (I checked and they appear to be)
  3. Reset the Y dimension on the elements on the ViewDidLoad method but that seems wrong.

Here's my push the new view onto the stack code:

[[UIDevice currentDevice] setOrientation:UIInterfaceOrientationPortrait]; 

ResultSelect_ViewController *resultSelect = [[ResultSelect_ViewController alloc] initWithNibName:@"ResultSelect" bundle:nil];
[self.navigationController pushViewController:resultSelect animated:YES];

Anybody else find it odd that the simulator doesn't allow you to test the upside down to portrait behavior?

+1  A: 

Typically you wouldn't support the upside down orientation. That seems to be the standard Apple app behavior and makes sense. The upside down case is not really useful and can cause confusion to the user.

We had a similar problem where subviews would migrate up and down the main view when flipping through the upside down case. We just stopped supporting upside down and that basically solved the problem.

Jason
Great idea, unfortunately I need all 4 directions (compass directions aren't as good with only 3 :) ).
Epsilon Prime
+2  A: 

Just to note: Apple started using a static (maybe even dynamic) analyzer and blocks apps that use private methods (e.g. setOrientation:) from entering the store. Happened to a friend of mine last week.

Have you tried building against iPhone OS 3.0 and relying only on shouldRotateToInterfaceOrientation:? The behaviour seems to be fixed (compared to the implementation in 2.x) and - at least for me - does the job.

Pascal
shouldRotateToInterfaceOrientation is called only when a rotation occurs. Since the navigationController is pushing a new view controller onto the stack it's sidestepping that check. It's starting to look like I'll need to file a bug with Apple on this one.
Epsilon Prime
Oh, you mean in a NavigationController only? Sorry, haven't tested; I have a NavigationController that can rotate to landscape, but a modal view that should always be portrait. Now when I have the iPhone landscape and the NavigationController displays landscape, and I call the modal view - which always returns a `NO` for the `shouldRotateToInterfaceOrientation:` - it pops up in portrait mode.
Pascal
Interesting. I wonder if I could pop up a modal view to fix the orientation and then dismiss it immediately...
Epsilon Prime
Okay, I tested popping up a modal view that only handles the desired orientation (portrait) then I immediately dismissed it. It went straight back to the orientation it had before I did the rotation.
Epsilon Prime
A: 

The way to avoid the rotation bug when rotating from upside down to portrait is not to do it. Instead, rotate twice stopping halfway (say UIDeviceOrientationLandscapeRight). The question of timing is not to use sleep but instead implement didRotateFromInterfaceOrientation and fire the second rotation (or push to next view) at that point.

Epsilon Prime