iOS 6.0 ограничивает автоматическое вращение в навигационном контроллере?

Что еще мне делать?

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

- (NSUInteger)supportedInterfaceOrientations
{
    return UIInterfaceOrientationMaskPortrait;
}

-(BOOL)shouldAutoRotate
{
    return NO;
}

Мой viewController все еще вращается.

Он встроен в стек навигации. Если я создам подкласс UINavigationController и реализую там те же шаблоны, предназначенные только для портретов, и встрою свой viewController в этот измененный navigationController, это сработает, но я не собираюсь переписывать свой код везде, где появляется UINavigationController.

Какова лучшая практика здесь?


ios uinavigationcontroller uiviewcontroller uiinterfaceorientation autorotate
person Geri Borbás    schedule 18.10.2012    source источник
comment
вы уже решили проблему, вы должны создать подкласс UINavigationController   -  person CSmith    schedule 18.10.2012
comment
Это то, что я сделал до сих пор, но я использовал представленныйViewController вместо topViewController. Почему мы все равно должны наследовать эти свойства вручную?   -  person Geri Borbás    schedule 18.10.2012

Ответы (2)


arrow_upward
6
arrow_downward

ОРИГИНАЛЬНЫЙ ОТВЕТ: Не нужно создавать подклассы - просто создайте категорию, как я описал в своем решении здесь: -simulator-not-working/12518577#12518577">Портретная ориентация верхней домашней кнопки в симуляторе iOS6 не работает

По сути, для iPhone UINavigationController разрешает вращение для всего, кроме «портрета верхней домашней кнопки», для iPad он разрешает все.

Итак, либо вы делаете категорию, пересылающую решение на текущий активный контроллер представления, либо что-то статическое, например

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

ОБНОВЛЕНИЕ: Как указал Хавьер Сото, это может привести к неопределенному поведению, если вторая категория делает то же самое. В этом случае подклассы могут быть лучшим решением.

В ситуации, когда вы знаете, что ни одна другая категория не делает то же самое, я по-прежнему считаю это рабочим, не требующим больших усилий, локальным и прагматичным решением. Я не религиозен в этом. Сам решай.

person Christoph    schedule 18.10.2012
comment
Спасибо, я сделал то же самое, просто спросил topViewController о его собственных свойствах. Если бы я хотел ограничить все, кроме портретной ориентации, я бы снял флажок с поддерживаемых ориентаций в информации о развертывании. - person Geri Borbás; 18.10.2012
comment
Добавление категории, переопределяющей метод другого класса, приводит к неопределенному поведению, этого никогда не следует делать. Тот факт, что это работает прямо сейчас, заключается в том, что iOS в конечном итоге использует вашу реализацию после загрузки категории, но это может измениться. Кроме того, что произойдет, если более чем одна категория переопределит метод? Просто подкласс, это ужасная идея. - person Javier Soto; 12.07.2013
comment
Это работало/отлично работает на iPhoneOS 3.0 до iOS6.1.3. Он отлично работает, если вам приходится использовать сторонние компоненты, которые вы не можете изменить. И моя главная причина сделать это именно так: это единственное локальное изменение, в то время как замена UINavigationController подклассом во многих местах является операцией дробовика. - person Christoph; 12.07.2013
comment
Также под ВАШИМ контролем, сколько категорий переопределяет методы - пока вы делаете это только один раз, все в порядке. - person Christoph; 12.07.2013
comment
Нет, это не так. Что делать, если есть другая категория в .a, на которую вы ссылаетесь в своем приложении? Вы не можете знать. Вы никогда не должны переопределять методы в категориях, это неопределенное поведение. - person Javier Soto; 12.07.2013

arrow_upward
3
arrow_downward

Вы должны наследовать от UINavigationController и везде использовать свой собственный. Это не так уж и много работы (просто найдите в своем коде вхождения UINavigationController). Это окажется гораздо более гибким, потому что вы сможете настроить другие вещи, если это необходимо.

НИКОГДА не делайте этого в категории, которая переопределяет методы в основном классе, как предлагает другой ответ.

person Javier Soto    schedule 11.07.2013
comment
Это работало/отлично работает на iPhoneOS 3.0 до iOS6.1.3. Он отлично работает, если вам приходится использовать сторонние компоненты, которые вы не можете изменить. И моя главная причина сделать это именно так: это единственное локальное изменение, в то время как замена UINavigationController подклассом во многих местах является операцией дробовика. Сюда также могут входить раскадровки и другие файлы XIB/NIB. - person Christoph; 12.07.2013
comment
Вам не нужно изменять сторонние компоненты, потому что они управляют своей собственной ориентацией. Использование категории для замены метода другого класса приводит к неопределенному поведению. Период. - person Javier Soto; 12.07.2013
comment
@JavierSoto Это неправильно. Методы в категории всегда переопределяют методы класса. Вы получаете неопределенное поведение, только если у вас есть две категории, переопределяющие один и тот же метод. (И это не совсем неопределенно, какая бы реализация ни была загружена последней, побеждает.) - person Jakob Egger; 09.08.2013
comment
Это правильно, но поскольку, когда вы добавляете категорию, вы не можете знать, добавит ли ее что-то еще, вы никогда не должны переопределять методы. Это не undefined ПРЯМО СЕЙЧАС, но оно может измениться, вы будете полагаться на недокументированное поведение. - person Javier Soto; 10.08.2013