Автоматическая компоновка недействительна после представления контроллера вида (и многих ситуаций)

История:

У меня есть пользовательский контроллер контейнера, который точно так же, как UITabBarController, но с анимацией переключения. И я использую автоматический макет для достижения.
Поскольку переключатель между дочерними контроллерами является динамическим, соответствующие ограничения добавляются в контроллер дочернего представления, когда его представление добавляется в представление контейнера, а не предварительно настраивается в IB. (Конечно, ограничения добавляются в супервизор)

http://d.pr/i/q6NF Настройка контейнера контейнера

PS: Деталь ограничений
H: | [Child] (изменить константу ограничения на анимацию слева/справа налево/влево)
H: [Ребенок (== Супер)]
V: | [Ребенок] |

Где проблема:

Один из дочерних контроллеров является навигационным контроллером, все идет не так, когда навигационный контроллер представляет собой контроллер модального представления (используя presentViewController:animated:completion:) и отклоняет его (используя dismissViewControllerAnimated:completion:), после того, как он появился/отклонил рамку навигации контроллер становится (x, y, 0, 0), Кажется, что автоматическая компоновка становится недействительной, возможно, ограничения были удалены.

http://d.pr/i/VmvL Настоящий/Отклоненный процесс

Исследование

Я еще не использовал код для проверки того, что происходит с этими ограничениями, но с помощью Spark Inspector я вижу изменение представления представлений во время текущего/увольнения процесса. Когда мой контроллер навигации представляет собой контроллер модального представления, iOS просто свопинг весь вид контроллера навигации в режиме просмотра модального представления. И когда появится представление контроллера навигации, автомат не работает больше.

Возможное решение

Одно из решений, которое я придумал, - это позволить моему контроллеру контейнера иметь модальный контроллер.

Или я просто изменяю свой контроллер контейнера без автоматического макета.

Факт с тех пор, как я начинаю использовать автоматическую компоновку, проблемы, которые этот метод заставляет просто доминировать над преимуществами. Помимо этой проблемы. Каждый раз, когда меняется ориентация интерфейса, представления внутри моего контроллера контейнера просто не могут автоматически настраивать макет, кажется, что в subviews всегда используется рамка супервизора перед изменением ориентации. Я дважды проверяю ограничения, которые я настраиваю, конфликтов нет и нет двусмысленности.

Мое предположение заключается в том, что мой пользовательский контроллер контейнера несовместим с представлением модального контроллера и изменением ориентации интерфейса в системе автоматического макета даже при настройке ограничений.

Xcode Environment

Xcode 5 beta, iOS 7SDK, target iOS6.1 Возможно, что-то не так с средой SDK?

Итак, я отправляю этот вопрос, пожалуйста, помогите мне!

Это мой первый вопрос, поэтому у меня недостаточно репутации для отправки изображений, но я предоставляю ссылки для скриншотов. Извините за это!

Ответ 1

У меня была похожая проблема . Я установил translatesAutoresizingMaskIntoConstraints = NO; в свой корневой UIView. Он выглядит как "самый внешний" UIView - супервизор в корне вашей иерархии должен использовать значение по умолчанию translatesAutoresizingMaskIntoConstraints = YES. Как только я удалю это, все сработало, как ожидалось.

Ответ 2

Вероятно, это связано с неоднозначными ограничениями. Я рекомендую приостановить запущенное приложение и ввести следующую команду для консоли:

po [[UIWindow keyWindow] _autolayoutTrace]

Ответ 3

У меня тоже такая же проблема, и когда я пробовал этот контроллер навигации, он работал нормально, но не с текущим viewcontroller. Используйте этот метод контроллера вида ниже, а также переводитAutoresizingMaskIntoConstraints для решения этой проблемы.

-(void) viewWillLayoutSubviews
{
    [super viewWillLayoutSubviews];

    self.view.translatesAutoresizingMaskIntoConstraints = NO;
}

Пожалуйста, позвольте мне теперь, чтобы вы беспокоились об этом. Благодаря

Ответ 4

Если вы используете автоматическую компоновку между UIWindow и корневым представлением (чтобы задать корневой вид для заполнения всего UIWindow), эти ограничения будут сбиты полноэкранным представлением другого контроллера представления.

Что происходит, вся иерархия полноэкранной презентации заменяет все ниже UIWindow - ваше исходное представление удаляется (сбрасывает ограничения) и заменяется новая иерархия представлений. Затем, когда ваш обзор заменяется, эти ограничения теряются. Вам нужно будет воссоздать их где-то вроде viewWillAppear: или просто обеспечить, чтобы ваш корневой вид имел self.view.translatesAutoresizingMaskIntoConstraints = NO;

Ответ 5

У меня была аналогичная проблема с ячейками табличного представления, которые я планировал с помощью автозапуска. По возвращении с модального вида ячейки имели недопустимый макет. Я мог бы переустановить каждую ячейку после viewDidAppear, но выглядел ужасно. Благодаря предложению @palimondo я начал обнюхивать translatesAutoresizingMaskIntoConstraints. Оказывается, я настраивал представление содержимого моей таблицы представления таблицы на translatesAutoresizingMaskIntoConstraints = NO, когда я не должен был быть.

Ответ 6

У меня была та же проблема, с контейнером панели поиска как неуместным элементом (внутри UIViewController, внутри UITabBarController). Ни один из других решений, которые я видел, не работал, но мне в итоге удалось обойти его, повторно добавив ограничение макета в viewWillAppear:

[self.view addConstraint:[NSLayoutConstraint constraintWithItem: self.searchBar.superview
                                                      attribute: NSLayoutAttributeTop
                                                      relatedBy: NSLayoutRelationEqual
                                                         toItem: self.view
                                                      attribute: NSLayoutAttributeTop
                                                     multiplier: 1
                                                       constant: 0]];