Обнимание и сопротивление сжатию в вложенных представлениях

Я пытаюсь понять, насколько эффективны облегающие и компрессионные сопротивления.

У меня есть этот сценарий, где мне нужны две метки слева (внутри зеленого контейнера) и две метки справа (внутри синего контейнера).

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

Как показано на рисунке, я хочу, чтобы зеленый контейнер обнимал контент (Android wrap content) и синий контейнер, чтобы заполнить оставшееся пространство (Android fill_parent).

Я думал, что могу просто добавить приоритеты обнимания/сжатия в зеленый вид, например:

greenView.setContentHuggingPriority(
    UILayoutPriorityDefaultHigh, forAxis: .Horizontal)
greenView.setContentCompressionResistancePriority(
    UILayoutPriorityDefaultHigh, forAxis: .Horizontal)

Но похоже, что он работает не так, как ожидалось. Я должен использовать эти ограничения для (красных и желтых) меток.

Кто-нибудь знает причину?

Некоторые мысли (отредактированные):

Из ответа Ken следует, что вам нужно назначить обертку/сжатие меток вместо представлений контейнера.

В примере этого вопроса я бы установил, например, обхват 750 (высокий) и сопротивление 1000 (обязательно) на метки слева. Поскольку значения по умолчанию для меток обнимаются 251 (низкий + 1) и сопротивление 750 (высокий), обхват и сжатие будут больше для меток слева (750 > 251 и 1000 > 750). В то же время сжатие будет больше, чем обхват внутри самой метки (1000 > 750).

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

Уф!

Ответы

Ответ 1

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

[view(<[email protected])]
[view(>[email protected])]

Что все это значит. То же самое относится и к внутренней высоте.

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