setOrientation problem

Question

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?

Answer 1

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.

Answer 2

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.

Answer 3

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.