UIKit ;; hugging priority, compression resistance priority (+Intrinsic Size)
Hugging Priority와 Compression Resistance Priority
StackView의 Distribution.fill 의 설명에서
내부 컨텐츠들을 스택뷰에 채우는데, Hugging Priority와 Compression Resistance Priority에 기반한다고 했다.
따라서 Hugging Priority와 Compression Resistance Priority에 대해서 공부를 해보려고 한다.
Compression Resistance Priority
: the priority with which a view resists being made smaller than its intrinsic size.
(해당 뷰의 고유 크기보다 작아지지 않도록 하는 우선순위)
https://developer.apple.com/documentation/uikit/uiview/1622465-contentcompressionresistanceprio
contentCompressionResistancePriority(for:) | Apple Developer Documentation
Returns the priority with which a view resists being made smaller than its intrinsic size.
developer.apple.com
Compression Resistance Priority를
직역하면 "압축 저항 우선순위" 이다.
만일 압축 저항 우선순위가 높다면, 고유 크기보다 작아지지 않을 수 있다는 것이다.
반대로 압축 저항 우선순위가 낮으면, 저항 없이 고유 크기보다 작아질(압축될) 수 있다는 것이다.
Hugging Priority랑 헷갈릴 수 있는데
이렇게 단어의 뜻을 생각해보면 헷갈리지 않을 수 있다!
압축 저항이 높으면 쪼그라들지(압축) 않을 수 있겠구나~! (intrinsic size 유지)
Hugging Priority
: the priority with which a view resists being made larger than its intrinsic size.
(해당 뷰의 고유 크기보다 커지지 않도록 하는 우선순위)
https://developer.apple.com/documentation/uikit/uiview/1622556-contenthuggingpriority
contentHuggingPriority(for:) | Apple Developer Documentation
Returns the priority with which a view resists being made larger than its intrinsic size.
developer.apple.com
Hug는 누구나 의미를 다 알 것이다. 끌어 안다!
Hugging Priority를
직역하면 "끌어안는 우선순위" 이다.
만일 끌어 안는 우선순위가 높다면, 고유 크기보다 커지지 않을 수 있다는 것이다.
반대로 끌어 안는 우선순위가 낮으면, 저항 없이 고유 크기보다 커질(퍼질) 수 있다는 것이다.
이것도 마찬가지로
단어의 뜻을 생각해보면 헷갈리지 않을 수 있다!
끌어 안는 저항이 높으면 퍼지지 않을 수 있겠구나~! (intrinsic size 유지)
실습 >
<Hugging Priority>
1. 버튼 두 개를 양쪽에 배치하고 leading과 top Constraints를 30씩 추가해주었다.
버튼은 intrinsic size를 가지고 있으므로 width와 height를 주지 않아도 레이아웃을 잡을 수 있다.
전혀 문제가 없는 것처럼 보인다.
2. 하지만 Xcode 상에서 노란색 경고가 뜬다.
왼쪽 버튼은 Trailing constraint is missing, which may cause overlapping with other views.
오른쪽 버튼은 Leading constraint is missing, which may case overlapping with other views.
라고 한다.
즉, 왼쪽 버튼은 trailing constraint가 없고, 오른쪽 버튼은 leading constraint가 없어서 다른 뷰에 가려질 수도 있다~ 고 알려준다.
3. 그래서 첫번째 버튼의 trailing constraint를 두번째 버튼의 leading으로 설정해주었더니 에러 발생!
에러를 확인해보니
Set horizontal hugging priority to 251 이라고 한다.
왜 에러가 난 것일까?!
왼쪽 버튼의 trailing을 오른쪽 버튼의 leading으로 설정했으므로 두 버튼이 달라붙어야 한다.
하지만 시스템은 어떤 버튼의 크기를 키우고, 어떤 버튼의 크기를 유지할지 판단하지 못한다!!
따라서 에러가 발생한 것!
시킨대로 250으로 설정된 왼쪽 버튼의 default값을 251로 변경해보았다.
왼쪽 버튼의 hugging priority: 251, 오른쪽 버튼의 hugging priority는 250이다.
hugging priority 우선 순위가 낮은 오른쪽 버튼이 늘어난 것을 볼 수 있다.
아까 hugging priority는 끌어 안는 우선순위라고 했다. (intrinsic size 이상 커지지 않는 우선순위!)
따라서 우선 순위가 낮은 오른쪽 버튼이 퍼진 것이다.
<Compression Resistance Priority>
1. 버튼의 타이틀을 아주 길게 변경해본다. 에러 발생!
현재 상태는 hugging priority가 왼쪽이 더 높은 상태로, 오른쪽이 저항 없이 늘어나는 상태.
늘어나는 것만 설정한 것이므로 누가 줄어들 것인지를 설정하는 Compression Resistance Priority와는 다르다.
에러를 확인해보니, 왼쪽 버튼의 compression resistance priority는 낮추고,
오른쪽 버튼의 compression resistance priority는 높이라고 한다.
default값은 750이다.
2. 시킨대로 해봤다.
오른쪽 버튼의 compression resistance priority(압축 저항 우선순위)을 높였으니
오른쪽 버튼은 고유 크기를 유지할 수 있다.
내가 원하는 그림은 긴 타이틀을 가진 버튼의 타이틀이 한 줄에 다 나오도록(고유 크기를 유지하도록) 하는 것인데!
그래서 반대로 설정.
왼쪽 버튼의 compression resistance priority가 751, 오른쪽이 750으로
왼쪽 버튼의 압축 저항 우선순위가 더 높다.
따라서 왼쪽 버튼은 고유 크기를 유지하고
오른쪽 버튼은 고유 크기를 유지하지 못하고 쪼그라들었다.
정리
hugging priority가
높으면 intrinsic size(고유 크기) 유지,
낮으면 늘어남
(누가 늘어날 것인지를 설정)
compression resistance priority가
높으면 intrinsic size(고유 크기) 유지,
낮으면 쪼그라듦
(누가 줄어들 것인지를 설정)
priority가 높으면 크기를 유지할 수 있다는 것이고!
hugging이 낮으면 늘어나고
compressiong resistance가 낮으면 줄어든다.