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?
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.
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.