iOS 6.0 restrict auto rotation within a navigation

Question

What else should I do?

-(BOOL)shouldAutorotateToInterfaceOrientation:(UIInterfaceOrientation) toInterfaceOrientation
{
    return (toInterfaceOrientation == UIInterfaceOrientationPortrait);
}

- (NSUInteger)supportedInterfaceOrientations
{
    return UIInterfaceOrientationMaskPortrait;
}

-(BOOL)shouldAutoRotate
{
    return NO;
}

My viewController still rotates.

---

It is embedded in a navigation stack. If I subclass UINavigationController, and implement the same portrait-only templates there, and I embed my viewController in that tweaked navigationController, than it works, but I have no intention to rewrite my code everywhere a UINavigationController appears.

What is the best practice here?

Answer 1

You should inherit from UINavigationController and use your custom one everywhere. It's not that much work (just search for occurrences of UINavigationController in your code). This will turn out to be much more flexible cause you'll be able to customize other things if necessary.

NEVER do it in a category that overrides methods in the main class like that other response suggests.

Answer 2

ORIGINAL ANSWER: No need to subclass - just do a category like I described in my solution here: Top-home button portrait orientation in iOS6 simulator not working

Basically, for iPhone the UINavigationController allows rotation for everything except "top home button portrait", for iPad it allows everything.

So either you do a category forwarding the decision to the currently active view controller or something static like

UINavigationController-Rotation.h:

@interface UINavigationController (Rotation)
@end

UINavigationController-Rotation.m:

#import "UINavigationController-Rotation.h"

@implementation UINavigationController (Rotation)

#pragma From UINavigationController

- (BOOL)shouldAutorotate {

    return NO;
}

- (NSUInteger)supportedInterfaceOrientations {

    return UIInterfaceOrientationMaskPortrait;
}

#pragma -

@end

UPDATE: As Javier Soto pointed out, this might lead to undefined behavior if there is a second category doing the same. In that case, subclassing might be a better solution.

In a situation where you know there is no other category doing the same I still consider this a working, low effort, local and pragmatic solution. I am not religious about that. Decide yourself.