Автоматическое изменение размера масок программно по сравнению с Interface Builder / xib / nib

Question

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

Итак, я привык думать в соответствии с этим снимком:

Позже сегодня мне пришлось перепроверить и наткнуться на эту ветку .

А также на яблочную документацию, озаглавленную сраздел с заголовком - «Автоматическая обработка изменений макета с использованием правил авторазмера» по этой ссылке: https://developer.apple.com/library/content/documentation/WindowsViews/Conceptual/ViewPG_iPhoneOS/CreatingViews/CreatingViews.html

Итак, теперь у меня есть обновленное представление о том, как установка масок автоматического изменения размера программно эквивалентна настройкам XIB:

Сценарий 1 : Установка только (UIViewAutoresizingFlexibleWidth | UIViewAutoresizingFlexibleHeight) эквивалентна:

В XIB?

Сценарий 2 : установка (UIViewAutoresizingFlexibleWidth | UIViewAutoresizingFlexibleHeight | UIViewAutoresizingFlexibleLeftMargin | UIViewAutoresizingFlexibleRightMargin | UIViewAutoresizingFlexibleTopMargin | UIViewAutoresizingFlexibleBottomMargin) в коде эквивалентна:

В XIB?

Верны ли мои 2 обновленных сценария?Правильно ли я сейчас понимаю?

Answer 1

Да, вы правильно цитировали вещи.Кроме того, я согласен, что это выглядит немного задом наперед, поэтому я благодарен за ваш пост.

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

#define UIViewAutoresizingFlexibleMargins                 \
              UIViewAutoresizingFlexibleBottomMargin    | \
              UIViewAutoresizingFlexibleLeftMargin      | \
              UIViewAutoresizingFlexibleRightMargin     | \
              UIViewAutoresizingFlexibleTopMargin

Использование UIViewAutoresizingFlexibleMargins сделает элемент пользовательского интерфейса центрированным, поскольку он НЕ будет обниматься ни с одной стороны.Чтобы элемент увеличивался / уменьшался вместе с его родителем, установите UIViewAutoresizingFlexibleWidth и UIViewAutoresizingFlexibleHeight соответственно.

Мне нравится использовать UIViewAutoresizingFlexibleMargins, потому что позже я могу ссылаться на него следующим образом:

myView.autoresizingMask = UIViewAutoresizingFlexibleMargins;

вместо

myView.autoresizingMask = UIViewAutoresizingFlexibleBottomMargin | UIViewAutoresizingFlexibleLeftMargin | UIViewAutoresizingFlexibleRightMargin | UIViewAutoresizingFlexibleTopMargin;

Часто я вижу эти поля ИЛИвместе в одной строке, как в примере выше.Просто трудно читать.

Answer 2

Да, Интерфейсный Разработчик в некотором смысле «перевернул» (или UIView, в зависимости от того, как вы на это смотрите). Указанные вами "сценарии" верны.

Answer 3

Swift 4 используйте это

gadBannerView?.autoresizingMask = [.flexibleRightMargin  , .flexibleLeftMargin , .flexibleTopMargin , .flexibleBottomMargin]

Objective-C

myView.autoresizingMask = UIViewAutoresizingFlexibleBottomMargin | UIViewAutoresizingFlexibleLeftMargin | UIViewAutoresizingFlexibleRightMargin | UIViewAutoresizingFlexibleTopMargin;

Answer 4

Включение вертикальной / горизонтальной стрелки (называемой пружиной) внутри коробки сделает гибкость высоты / ширины.Но включение внешней линии (называемой распоркой) сделает эту сторону негибкой / негибкой.

Включение внешней левой линии (левая стойка) не эквивалентновключение UIViewAutoresizingFlexibleRightMargin.Вместо этого UIViewAutoresizingFlexibleRightMargin = вкл. , если правая распорка отключена, выкл. , если правая распорка включена.

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