오늘은 볼때마다, 제가 할때마다 헷갈리는
hugging priority, compression resistance priority에 대해서 파헤쳐 보는 날!
파헤진 다음 정리도 같이.. 제가 안 헷갈릴려고 정리하는 글인 셈이죠..
스토리 보드를 켜고 바로 실행해 봅시다.
LL, RR 이란 라벨을 width조건 없이, 그저 동일한 constraints(제약) 조건을 줘서 만들어봅시당
두 라벨 모두 top(200), leading(20), trailing(20)를 으로 줬더니 에러가 발생하네요.
에러 메세지를 직역 해볼게요.
content size ambiguity is caused when two or more views have the same content hugging or compression resistance priority and those view are not all currently at their intrinsic content size in the canvas.
콘텐츠 크기 모호성은 두 개 이상의 뷰가 동일한 콘텐츠 포옹 우선권(hugging) 또는 압축 저항 우선권(compression resistance)를 가지며 이러한 뷰들이 현재 캔버스에서 고유한 콘텐츠 사이즈로 있지 않을 때 발생합니다.
In this case Auto Layout does not know which view to grow or clip.
이 경우 Auto Layout(자동 레이아웃)은 어떤 뷰를 확장하거나 클리핑할지 모릅니다.
To fix, increase or decrease the content priorities of one of the views to indicate which view should grow or get clipped firset.
보기 중 하나의 내용 우선 순위를 수정, 증가 또는 감소하여 확장 또는 클리핑 할 뷰를 설정합니다.
그러니까, 저렇게 두 라벨이 있을 때
길이 지정이 안 된 뷰끼리 겹치는 제약 조건이 있지만 공간이 남을때,
어느걸 늘리거나 줄일지 몰라서 발생하는 에러라는 말이에요.
예시로 설명해보자면,
지금 LL의 trailing은 RR로부터 20, RR의 leading은 LL로부터 20
여기에 LL 자체의 leading은 20, RR의 trailing도 20
(RR은 오른쪽으로부터 20 떨어져 있으면서도, LL이랑 20만큼만 떨어져 있고,
그런 LL은 왼쪽이랑 20만큼만 떨어져 있어야 한다는 말)
벌써 말이 안 되죠?? 20,20,20 떨어져 있어야 하는데 우리는 크기(width)를 지정해주지 않았어요!
남은 공간에서 어떤 라벨을 늘리거나 줄여서 이 제약조건을 만족할 수 있는건지... 명시하지 않았어요.
이런 경우 사용하는 설정이 hugging priority입니다.
뭔지 모르겠으니까 냅다 한번 해봅시다.. 먼저 LL(왼쪽)에 있는 라벨의 hugging piority를 250으로 낮춰볼게요.
LL의 Horizontal의 우선순위를 낮춰봤어요.
그랬더니 우선순위가 낮아진 LL라벨이 늘어났네요. 이제 상하, 좌우 다 20씩 맞는거 같죠?!
우선순위가 낮아진 라벨은 자신의 길이를 유지하지 못하고 늘어나나봐요.
그러면 우선순위가 높다 == 자신의 원래 길이를 유지한다 라고 보면 될까요 ??
확실하게 비교를 위해서 반대로 Horizontal 우선순위를 252로 높여 볼게요. (251보다 크게 252로!)
이러면 우선순위가 높으니까 label에 내용이 있는만큼 길이를 유지할까요 ??
그렇네요! 우선 순위가 높아졌으니까 라벨 내용만큼의 길이를 유지하고,우선순위가 작아진 라벨이 늘어나요.
흠, 그러면 LL이 길이가 길어지면 어떻게 될까요?
RR은 LL의 길이에 맞춰서, LL보다 우선순위가 낮기 때문에 자신의 내용 길이를 유지하지 못하고 늘어납니다.
그러니까 정리하자면,
우선순위가 낮아지면, 원래 길이를 유지하지 못하고 늘어나는 거에요!
이게 숫자가 작아지는데 길이는 늘어나..? 해서 헷갈리는데 저는.. 이렇게.. 생각했어요.
hugging priority를 직역하면 포옹 우선순위
그래서 포옹 우선순위가 작아지면 포옹을 못하고 밀어내기 때문에 늘어난다고 생각했어요!
(좀 웃기지만,, 이렇게 생각하면 나름 쉬울수도,,,)
정리하자면,
hugging priority는 width를 지정하지 않았을 때,
남은 공간에서 누가 늘어나고 줄어들지를 정해주는 제약이에요.
여기서 우선순위가 낮아지면, 안지 못하니까 원래 길이를 유지하지 못하고 늘어납니다.
근데 여기서.. 라벨 둘 다 text 양이 많아지면 어떻게 될까요??
이렇게 그대로 길어지면서, 한쪽이 잘리게 되어 버려요..
그러면서 이런 오류가 발생하죠
Increase horizontal compression resistance of "RRRRR......"
from 750 to 751 to keep its intrinsic width before other views.
"RRRR..."의 수평 압축 저항을 750에서 751로 증가시켜 다른 뷰보다 고유한 너비를 유지합니다.
지금 RR...의 라벨에 내용이 더 많으니까 compression resistance을 증가해서 라벨 내용을 더 보여주라는 말일까요?
바로 확인해봅시다.
751로 바꾸었더니 RRRR...이 잘리지 않고 원래 길이 그대로 늘어났네요! (현재 LL : 750, RR : 751)
Compression resistance이 늘어나면, 자신의 길이를 유지하고, 다른 뷰의 길이가 줄어드나봐요!
확실하게 반대로도 LLLL의 compression을 751보다 큰 수인 752로 해볼게요! ( LL : 752, RR : 751)
반대로 LLL이 원래 길이를 유지하고, RRR이 줄어드네요!
compression resistance은 우선순위가 높아지면, 그 길이 값을 유지하고 다른 뷰가 작아지도록 만들어주네요!
엥 hugging이랑 뭐가.. 다른거지? 싶으실텐데,
hugging 이랑 다른 상황이 뭔지 잘 생각해보면 어렵지 않아요.
지금 이 두 라벨은 둘 다 텍스트가 많아서 공간이 부족한 상태에요! 근데 아까 hugging은 공간이 남았어요.
이게 포인트입니다. 두 개는 같이 생각하면 안 돼요. 따로따로!
두 뷰가 공간이 남는데 사이즈 조절을 해야한다! 하면 hugging priority
두 뷰가 공간이 부족해서 사이즈를 조절해야 한다! 하면 compression resistance priority
그래서 지금 여기 두 라벨의 hugging값을 250으로 동일하게 맞추어도 에러가 나지 않아요!
왜나면 공간이 남는게 아니라 부족하니까 줄어들 라벨을 선택해주는거니까요.
그래도 헷갈리면 아까 위에서 직역을 생각하면서.. 확인해보도록 하죠.
compression resistance priority = 압축 저항 우선순위
압축 저항 우선순위가 높아진다는 것은 압축을 안 한다는 의미겠죠, 그러니까 낮은 쪽이 압축되는거에요.
압축 저항 우선순위가 낮아진다는 것은 압축한다는 의미겠죠, 그러니까 높은 쪽이 길이 유지!
* 추가로 한쪽 뷰의 내용을 그냥 냅다 막 길게 해버리면.. (예를 들어 RR)
LL은 아예 안 보이고 RRRRRRRR... 이렇게만 뜨는데 그렇게 뜨더니 예상치 못한 오류 메세지가 뜨면서 종류되더라구요..ㅎ
그렇게는 하면 안 되는 건가봐요.
최종으로 표로 보기 쉽게 정리해볼게요.
정리하니까 속이 시원하네요.
매번 헷갈려서 강의에 나오면 그런가보다.. 하고 넘어갔는데 싹 정리하고 넘어가봅니다.
혹시 틀리거나.. 뭔가 이상하다 싶은 내용이 있다면 말씀주세요!
'Swift > Swift Auto LayOut' 카테고리의 다른 글
| [Swift / Auto LayOut ]StackView를 알아보자 (2) | 2023.02.22 |
|---|
