UIView와 UILabel의 autoLayout을 지정할 때 방식이 조금 다른걸 알고 왜 다른지 한번 알아보겠습니다!
공식 문서를 우선 살펴보면 CustomView는 레이아웃 시스템이 content를 인식하지 못하지만 intrinsicContentSize의 프로퍼티를 설정하게 되면 content에 기반한 사이즈를 CustomView이 레이아웃 시스템과 통신할 수 있습니다.
이러한 intrinsicContentSize은 content Frame과 무관하다. 변화하는 높이에 기반으로 변경된 width의 레이아웃 시스템에 동적으로 전달하는 방법이 없다.
https://babbab2.tistory.com/135
UILabel VS UIView
AutoLayout을 지정할 때 UILabel을 조절할 땐 top, left 등 수직 방향과 수평 방향에 대한 autolayout만 지정해주면 된다.
UIView의 경우엔 x,y좌표와 width,height에 대한 autolayout을 모두 지정해줘야 한다.
이렇게 UIView와 UILabel을 오토레이아웃을 지정하는 방법이 다른 이유는
intrinsicContentSize이다.
말 그대로 컨텐츠의 본질적인 크기이다. UILabel은 Height, Width에 대한 컨텐츠 사이즈를 가진다!
다음과 같이 UIView의 경우엔 intrinsicContentSize가 없다.
그래서 오토레이아웃을 지정할 때 좌표 정보와 크기에 대한 정보를 반드시 지정해줘야 한다.
Priority
말 그래도 AutoLayout에 대한 우선순위이다.
오브젝트가 하나일 땐 큰 문제가 되지 않는다. 두개일 경우에 우선순위가 높은 오브젝트는 자신의 크기를 먼저 갖고 고정이 된다. 반대로 우선 순위가 낮으면 높은 크기의 View가 정해지고 그 뒤에 설정된 값으로 지정된다.
다음과 같이 UILabel일 top,leading/ top,trailing만 지정해줬다.
이럴 경우에 왼쪽은 trailing이 없는 에러, 오른쪽은 leading이 없는 에러가 발생한다. 이를 해결하기 위해 두 UIlabel이 서로에 대한 AutoLayout을 지정해주게 되면 다음과 같은 에러가 발생합니다.
이렇게 동일한 우선 순위가 동일하기 때문에 둘 중에 하나의 우선 순위를 변경하라는 에러문구가 발생합니다.
Content Hugging Prority
이렇게 서로에 대한 Auto layout을 지정한 경우엔 UILabel에서 가지고 있는 Intrinsic Width를 유지하지 못하게 된다.
AutoLayout에 대하여 둘 중에 하나는 IntrinsicSize를 유지하지 못하게 된다. 하지만 둘 다 우선순위가 똑같기 때문에 어떠한 UILabel을 AutoLayout으로 설정해야하고 Intrinsic Size로 지정해야할 지 시스템에서 구분할 수 없다.
기존에 default로 설정된 Hugging 우선순위는 251이지만 좌측에 있는 UILabel의 우선순위를 하나 올려줬다.
실행 결과 좌측의 Intrinsic Size를 사용하고 있고 우측의 UILabel은 auto Layout을 이용해 크기가 지정되어있다.
우선 순위가 높은 것에 대하여 Intrinsic Width를 사용한다!
반대로 우측에 대하여 Hugging Priority를 253으로 높혀주면 다음처럼 변한다!
Content Compression Resistance Priority
만약 UILabel들이 컨텐츠의 길이가 너무 커서 충돌이 발생하는 경우가 있다.
이럴때 어떠한 Label의 intrinsicContentSize 유지하고 어떤것을 줄일지를 결정하는 것이 Compression Resistance Priority이다!
앞서 본 Hugging Priority와 반대의 개념인 것 같다.
즉, 우선 순위가 높은 것은 사이즈를 유지하고 작은 것은 줄어든다.
좌측의 Compression Resistence 우선순위를 하나 높이게 된다면
충돌하는 것 없이 잘 작동하는 것을 볼 수 있다.
