Question

As far as I know the correct practice on iOS 6 is to write a code like this to handle autorotation:

// iOS 6
- (BOOL)shouldAutorotate {
    return YES;
}

- (NSUInteger)supportedInterfaceOrientations {
    return UIInterfaceOrientationMaskPortrait;
}

Instead of writing

// pre-iOS 6 support
- (BOOL)shouldAutorotateToInterfaceOrientation:(UIInterfaceOrientation)toInterfaceOrientation {
    BOOL retVal = UIInterfaceOrientationIsLandscape(toInterfaceOrientation);
    return retVal;
}

To be honest, I think that the pre-iOS 6 is much more clear: I don’t understand the point of having 2 methods to handle autorotation, specially because I’ve seen -(BOOL) shouldAutorotate returning YES in all the examples. Am I missing something?

Answer 1

The new API lets you save a call to get the current device orientation: the two questions, namely

• Whether or not the application should auto-rotate, regardless of the new orientation, and
• What are the orientations a device supports

are most often answered statically, without making a call to check the current orientation. The savings become more important when a screen has multiple views controlled by separate view controllers.

Since the iOS is making a call into your app’s shouldAutorotate in response to an event from the accelerometer, it already knows the new orientation; if your app answers ‘YES`, the iOS could then check the current orientation against the list of supported ones, and come up with a decision without your app querying for the current orientation.

In the unlikely case that your app needs to decide on auto-rotation based on the new orientation, the new API is no worse than the old one, so it’s a “win-draw” situation.