[UIKit][AutoLayout] 오토레이아웃 개념 - Priority

Uno·2021년 8월 26일

UIkit

UIKit

목록 보기

2/9

오토레이아웃에 대하여

오토레이아웃은 “방정식” 입니다.

1차 방정식으로 각 UI 컴포넌트간 x, y에 대한 Postion 그리고 width와 height를 설정하죠.
그런 방정식들이 여러개가 모이고,

x나 y 값에 Device의 크기라는 상수가 할당되면,

“화면” 이라는 “해” 가 구해지게 될 것이고, 화면을 구성할겁니다.

그런데, 이 방정식이 충돌하는 경우가 발생합니다. 그런 경우 “우선순위”를 결정해서 문제를 해결할 수 있습니다.

그 개념이 Hugging priority 와 Compression Resistance priority 입니다.

Hugging priority, 들러붙어있는 우선권

Hugging? 허그한다고? ~~동방신기…~~

끌어안는 것에 대한 우선순위
이해가 안되죠?

A라는 친구의 길이가 100입니다.
B라는 친구의 길이도 100입니다.
그리고 아래 도식처럼 좌우 벽에 10의 간격을 유지해야하고, 둘의 간격은 20으로 유지해야합니다.

|--10--|A|--20--|B|--10--|

그런데 양 벽의 끝이 10+10+20+200 = 240 이면 아주 화목하게 A와 B가 공존할 수 있습니다.

문제는 만약 240보다 크면 어떻게 될가요?

A와 B의 길이, 즉 View(A)’s Width OR View(B)’s Width 값이 늘어나야겠죠.

그런데 둘은 서열정리를 하지 않았습니다. 아직 누가 형님인지 모릅니다.

그래서 개발자인 우리가 결정해줍니다.

오늘부터 A가 형님이다. 모셔라.

그러면 A는 형님이므로 움직이지 않습니다.

B가 움직여야죠
그래서 아래와 같이 될겁니다.

|--10--|A|--20--|   B   |--10--|

B가 꼭 다리를 찢어셔 방정식을 맞추고 있는 모양입니다.

Hug의 뜻이 “끌어안다” 도 있지만 “딱 들러붙다” 의 뜻도 있는겁니다.

그래서 Hugging Priority는 들러붙어있는 우선권 으로 받아들이시면 됩니다.

정리하자면, Hugging Priority 가 높으면, 늘어나지 않습니다.

Compression Resistance priority

Compression Resistance?

압축에 저항하는 우선순위..

해석만해도 느낌이 옵니다.

압축되지 않으려는 성질이구나

최소한의 사이즈를 유지할 수 있겠네요.

다시 A와 B를 불러왔습니다.

|--10--|A|--20--|B|--10--|

평화롭게 위와 같은 관계를 유지하고 있습니다.

그런데 여기서 A의 Label.text 가 길어져서 B를 침범하면 어떻게 될까요?

B는 밀리다가 왼쪽 벽을 뚫고 나가면서 오토레이아웃 경고창이 뜰겁니다.

그런데 우리는 B의 크기는 보존하고 싶다면?

Compression Resistance priority 를 높혀서 찌그러지지 않도록 해줍니다.
[image:CF74520B-A913-41FF-BF64-1303E1D3EE06-945-00000112ED514D0F/A02D4207-1880-4AF8-9C0B-0E1C9FD22442.png]

아래처럼요.

자연스럽게 a가 …로 글자가 생략이 되어버렸죠.

Compression Resistance priority는

정리하자면, Compression Resistance priority 가 높으면, 찌그러지지 않습니다.

정리

Q. 오토레이아웃이란 무엇인가?
Q. “Hugging priority” 란 무엇인가?
Q. “Compression Resistance priority” 란 무엇인가?
Q. Hugging priority 과 Compression Resistance priority 은 언제 사용하는가?

에 대한 답을 할 수 있도록 글을 작성했습니다.

읽어주셔서 감사합니다.