XCode 8.2.1 Autolayout: проблемы с занятыми, заполненными UIViewController

У меня есть проект в XCode 8.2.1, Swift 3, в котором есть много UILabels, UIButtons и UITextFields, показывающих много данных (по сути, форм). Приложение предназначено только для iPad, только в альбомной ориентации и ориентировано на 9.0 и выше.

Я пробовал назначать ограничения вручную (что занимает много времени), и я попытался разрешить IDE «Добавить отсутствующие ограничения» и «Сбросить до рекомендованных ограничений» в раскадровке. Если я удалю все ограничения из VC, он получит почти правильную «форму», но некоторые вещи все еще неуместны.

Я ничего не делаю в viewDidLoad () или в любом другом коде, связанном с позиционированием.

Вот скриншот моей Раскадровки: введите описание изображения здесь

А вот тот же UIViewController в симуляторе iPad Air 2 (iOS версии 10.2) с предлагаемыми ограничениями: < img src = "https://i.stack.imgur.com/A6z7Z.png" alt = "Раскадровка визуализирована с использованием сброса / предлагаемых ограничений">

a) Как следует использовать автопрокладку с тоннами необходимых элементов управления, когда важны интервалы и выравнивание? б) Почему XCode изменяет размер кнопок и элементов управления, которым я специально назначаю размеры? Мне приходится время от времени изменять размер вещей, когда раскадровка снова открывается.

Ценю любые предложения. Утомительно, и я трачу больше времени на макет, чем на функциональность, в отличие от версии 7.3 и старше.


xcode ios ios-autolayout
person Bat Lanyard    schedule 25.01.2017    source источник
comment
Вы должны укусить пулю, я боюсь, может быть, разбить разделы на их собственные подвиды, чтобы логические разделы могли быть автоматически сопоставлены с другими разделами, вместо того, чтобы отслеживать каждый элемент пользовательского интерфейса по сравнению с другими   -  person Fonix    schedule 25.01.2017

Ответы (1)


arrow_upward
1
arrow_downward

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

введите здесь описание изображения

Основное представление состоит из двух представлений контейнера. Контейнер слева включает UIableViewContoller, контейнер справа - UIViewController. Затем сам UIViewController встраивает другой UITableViewController. Каждый контроллер передает необходимые изменения в резервную копию цепочки контейнеров через делегатов.

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

Во-вторых, возможно, у вас есть класс мегаконтроллера, который управляет всей логикой для всех тех представлений, которые вы там втиснули. Когда вы разбиваете их на их собственные контроллеры, вы можете разбить мега-класс на отдельные классы, которые управляют только своим разделом пользовательского интерфейса, что делает код более читаемым и инкапсулированным.

person Frankie    schedule 25.01.2017
comment
Определенно добавляет сложности из-за цепочки, но, безусловно, имеет смысл. Должен был заметить, что у меня есть пара UIView-контейнеров в моем макете, но это еще один шаг вперед. Я попробую этот маршрут и доложу. Спасибо чувак. - person Bat Lanyard; 25.01.2017
comment
В конечном счете, я думаю, что это, вероятно, наиболее эффективно за то время, которое вы должны вложить в это решение. Спасибо за предложение. На данный момент я не использую Autolayout, поскольку это корпоративное приложение, поэтому у меня есть узкий целевой список для поддержки. Потратил полдня на группировку вещей в подвиды в контроллере, и это помогло, но все равно оставило это неуправляемым, не говоря уже о проблемах с добавлением чего-то нового. Автолайп отлично работает для одних видов, но для других - ад. - person Bat Lanyard; 25.01.2017
comment
Надеюсь, по крайней мере, эта идея поможет вам в долгосрочной перспективе, когда вы будете постепенно реорганизовывать приложение. Единственное, что может помочь, - это использовать представления стека, но при всех имеющихся представлениях вложение такого количества представлений стека может быть такой же головной болью. Удачи! - person Frankie; 26.01.2017