2

В моем приложении iOS 8 с использованием классов размера, чтобы iPad имел разную компоновку в портретной и альбомной ориентации, у меня есть IBOutletCollection для каждой ориентации, которую я активирую и деактивирую. Это значительно улучшилось вплоть до введения Container View.Ошибка при использовании activateConstraints в коллекции ограничений контейнера

Я добавляю новый VC, который является отдельным элементом табуляции в версии для iPhone, но я вставляю его в макет iPad с помощью Container View. Я сосредоточусь только на одном классе размеров, RegularRegular. Вид контейнера имеет 4 ограничения: трейлинг, ведущий, верхний и нижний. Когда я запускаю приложение, он выглядит отлично (в этой единственной ориентации).

Теперь, когда я добавляю эти 4 ограничения на мой IBOutletCollection, то activateConstraints сообщения выдает следующее сообщение об ошибке:

*** Нагрузочного приложение из-за неперехваченное исключение «NSGenericException», причина: «Не удалось активировать ограничение с элементами; layer =; contentOffset: {0, 0}; contentSize: {460, 78}> и>, потому что у них нет общего предка. Имеются ли ссылочные позиции ограничений в разных иерархиях представлений? Это незаконно.

Ограничения не ссылаются на элементы в разных иерархиях представлений. Top, Bottom и Leading - все это относится к другому представлению, которое также относится к мнению VC. Трейлинг относится к шагу, который также находится в представлении VC. Значит, они все на одном уровне иерархии.

Когда в отладке я вижу, что ограничение начинается с его свойства active как nil. Это кажется нормальным (неконтейнерные ограничения начинаются с того же самого, до того как они установлены на YES). Я проверил это с помощью цикла for, задающего свойство active.

Есть ли что-то, что я делаю неправильно с ограничениями на представление контейнера? Являются ли ограничения в представлении контейнера каким-то особенным, потому что они находятся в представлении контейнера? Я попытался найти ответ сам, но я не могу найти ничего в этом вопросе, который у меня есть.

Любая помощь будет принята с благодарностью.

4/10 Редактировать, чтобы представить фотографии & код. Обратите внимание, что в это время я разбил ограничения контейнера в отдельный массив, чтобы я мог справиться с ними самостоятельно.

На приведенном ниже изображении ограничения ведущего, верхнего и нижнего контейнера относятся к виду справа от контейнера. Ограничение Trailing связано с шагером над ним. VC Layout

код Похожие:

@property (strong, nonatomic) IBOutletCollection(NSLayoutConstraint) NSArray *regularAnyConstraints; 
@property (strong, nonatomic) IBOutletCollection(NSLayoutConstraint) NSArray *regularAnyContainerConstraints; 

@property (strong, nonatomic) IBOutletCollection(NSLayoutConstraint) NSArray *anyRegularConstraints; 
@property (strong, nonatomic) IBOutletCollection(NSLayoutConstraint) NSArray *anyRegularContainerConstraints; 

Эти ограничения в _anyRegularContainerConstraints массиве: _anyRegularContainerConstraints

[NSLayoutConstraint deactivateConstraints:_regularAnyConstraints]; 
[NSLayoutConstraint activateConstraints:_anyRegularConstraints]; 

[NSLayoutConstraint deactivateConstraints:_anyRegularContainerConstraints]; 
[NSLayoutConstraint activateConstraints:_anyRegularContainerConstraints]; 

ответ

1

Когда в отладке, я могу видеть, что ограничение начинается с его активная собственность как ноль

Это замечание заставляет меня задаться вопросом, можете ли вы неверно истолковать, что делать activateConstraints и deactivateConstraints.Несмотря на их имена и, несмотря на вводящие в заблуждение записи в документации, они фактически добавляют и удаляют ограничения. Таким образом, вместо того, чтобы смущать себя этими командами, я предлагаю вам лучше позвонить по телефону addConstraints и removeConstraints. Преимущество этого является:

  • Этих последние UIView методы, так что вы будете в сознательном контроле того, что просматривать ограничения будут добавлены в.

  • При удалении вы будете четко осознавать свою ответственность за сохранение удаленных ограничений, если вы хотите использовать их позже.

Я понимаю, что это не отвечает на вопрос прямо, но вы не предоставили достаточно информации для этого (вы не показали свой код, который вызывает activateConstraints и deactivateConstraints, вы не показали схему диспетчера представлений и иерархии представлений и т. д.), поэтому не совсем понятно, где вы ошибетесь. Вместо этого я пытаюсь вас переориентировать , думая, когда вы пытаетесь разобраться в деталях проблемы.

+0

Я пробовал это, но, похоже, все еще получаю ошибку иерархии, что заставляет меня думать, что с моей иерархией определенно что-то не так, но я не знаю, что. '[self.containerView removeConstraints: _regularAnyContainerConstraints]; [self.containerView addConstraints: _anyRegularContainerConstraints]; ' Сообщение об ошибке: Вид иерархии не готов к ограничению: \t При добавлении в целях , элементы ограничения должны быть потомками этого представления (или самого представления). –

+1

Ну, вид контейнера _are_ особенный в довольно очевидном виде. Я предполагаю, что мое следующее предложение будет: можете ли вы уменьшить эту проблему до очень простого проекта? Затем вы можете опубликовать его в github, а затем я загружу его и просмотрю детали. – matt

+0

Я должен был попытаться упростить его с самого начала. У меня нет проблем с активацией и деактивацией ограничений в отношении Container View из моего тестового проекта. Мне нужно исследовать различия между ним и моим проектом приложения. Благодарю. –

1

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

Чтобы решить эту проблему, теперь у меня установлен контейнер для AnyAny. Затем я отменил выбор всех классов размеров, которые я не хочу, чтобы они присутствовали.

Я в конце концов обнаружил, что это проблема, потому что мой контейнер UIView не был в self.view.subviews.