Przytulność i odporność na ściskanie w zagnieżdżonych widokach

Question

Próbuję zrozumieć, jak naprawdę działa opór przy ściskaniu i ściskaniu.

Mam ten scenariusz, w którym potrzebuję dwóch etykiet po lewej (wewnątrz zielonego pojemnika) i dwóch etykiet po prawej (wewnątrz niebieskiego pojemnika).

Jak widać na zdjęciach, chcę zielony pojemnik przytulić treści (Android wrap content) i niebieski pojemnik wypełnić pozostałą przestrzeń (Android fill_parent).

Myślałem, że mogę tylko dodać priorytety przytulanie/kompresja na zielonym świetle, jak:

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

Ale wydaje się, że to nie działa zgodnie z oczekiwaniami. Muszę zastosować te więzy na etykietach (czerwonej i żółtej).

Ktoś zna przyczynę?

Niektóre myśli (red):

Od odpowiedź Kena wynika, że ​​trzeba ustawić przytulanie/kompresję do etykiet zamiast poglądów kontenerowych.

W przykładzie tego pytania ustawilabym na przykład przyleganie 750 (Wysokie) i opór 1000 (Wymagany) na etykietach po lewej stronie. Ponieważ wartości domyślne dla etykiet to przytulanie 251 (niski + 1) i opór 750 (wysoki), przytulanie i kompresja będą większe dla etykiet po lewej stronie (750> 251 i 1000> 750). W tym samym czasie kompresja będzie większa niż przyleganie do samych etykiet (1000> 750).

W ten sposób etykiety po lewej będą próbowały uścisnąć treść, ale nie tak, aby ją skompresować. Na przykład czerwona etykieta nie może całkowicie zawinąć zawartości, ponieważ żółta etykieta nie chce kompresować.

Uff!

Answer 1

Priorytety dopasowania i odporności na kompresję mają znaczenie jedynie w stosunku do rzeczywistego rozmiaru zawartości widoku. Zasadniczo, jeśli widok ma szerokość wewnętrzną treść, system automatycznej układ traktuje go tak, jakby był z zastrzeżeniem następujących ograniczeń:

[view(<=intrinsicWidth@contentHuggingPriority)] 
[view(>=intrinsicWidth@compressionResistancePriority)] 

to wszystkie te myśli. To samo dotyczy oczywiście samej wysokości wewnętrznej.

Zwykły UIView używany jako pojemnik nie ma wewnętrznego rozmiaru. Tak więc priorytety dotyczące przyswajania treści i priorytetów kompresji są bez znaczenia.