ABOUT ME

-

Today
-
Yesterday
-
Total
-
  • Intrinsic Content Size, Content Hugging, Content Compression Resistance
    iOS 2021. 1. 24. 14:44
    728x90

    개인적으로 공부하며 정리하는 블로그 입니다.
    오류나 부족한 부분이 있을 수 있으니 감안하여 봐주시고 아낌없는 조언 감사드립니다 :D

     

    Intrinsic Content Size

    Intrinsic Content Size란 View의 콘텐츠(내용물)를 고려한 자연스러운 크기를 의미합니다.

    하지만 모든 뷰가 Intrinsic Content Size를 갖고 있는 건 아닙니다. 그냥 UIView 같은 경우엔 기본적으로 내용이 없는 빈 뷰이기 때문에 intrinsic content size를 갖지 않습니다. 반면, UIButton 같은 경우 title을 포함해 약간의 패딩까지 가지고 있습니다. 

    표로 간단히 정리해보죠.

    View Intrinsic Content Size
    UIView, NSView Intrinsic Content Size 가 없습니다.
    Sliders iOS는 width만 정의되어 있습니다.
    OS X에서는 타입에 따라 다르게 정의됩니다. width나 height 또는 둘다 정의될 수도 있습니다.
    Labels, buttons, switches, and text fields width 와 height이 모두 정의되어 있습니다.
    Text views and image views 달라질 수 있습니다.

     

    나머지는 바로 이해가 가실텐데 Text views and image views의 달라질 수 있다는 것에 대해 좀 더 알아보겠습니다.

    UIImageView 같은 경우 image가 없다면 intrinsic content size가 없습니다. image를 설정하는 순간 image의 크기가 intrinsic content size로 설정됩니다.

    UITextView 같은 경우 좀 더 많은 케이스가 있습니다.

    스크롤이 가능하다면 intrinsic content size는 정의되지 않습니다.

    스크롤이 불가능하다면 text를 기준으로 intrinsic content size가 정의된답니다.
    - 줄바꿈을 고려하지 않은 text의 크기가 intrinsic content size가 됩니다.
    - text가 없다면 한 줄의 나타낼 수 있는 widht와 height이 계산됩니다.
    - width constraint를 주었다면 주어진 width를 나타내는 텍스트를 기준으로 높이가 계산됩니다.

     

    CHCR Priorities (Content Hugging, Content Compression Resistence)

    Hugging과 Compression Resistence 모두 Intrinsic Content Size를 온전히 나타내기 위한 우선순위입니다.

    어떤 콘텐츠가 있을 때, 이 크기가 달라지는 경우를 크게 2가지로 생각해볼 수 있습니다.
    고유 콘텐츠 크기보다 더 커져버리는 경우와 고유 콘텐츠 크기보다 더 작아져서 콘텐츠가 잘리는 경우가 입니다.
    CHCR은 각각 이 두 가지 경우를 막기 위한 우선순위라고 생각할 수 있습니다.

    Content Hugging Priority는 고유 콘텐츠 크기보다 더 커져버리는 경우를 방지하기 위한 우선순위입니다.
    더 꽉 끌어 안는다는 의미로(허깅) Content Hugging Priority가 클수록 콘텐츠가 원래 크기보다 커져버리는 경우를 막습니다.

    Content Compression Resistence Priority는 고유 콘텐츠 크기보다 더 작아져버리는 경우를 방지하기 위한 우선순위입니다.
    압축되는 것에 대한 저항도 라는 의미로 Content Compression Resistence Priority가 클수록 콘텐츠가 원래 크기보다 작아져서 내용물이 잘리는 경우를 막습니다.

     

    이해를 돕기 위해 구체적으로 테스트를 한번 해보겠습니다 :)

    앞서 intrinsic content size를 공부하면서 우리는 text field는 고유 크기를 가지고 있다는 걸 알았습니다. 따라서 이렇게 두 개의 텍스트 필드를 놓고 위치만 잘 잡아주면 따로 크기를 정하지 않아도 아무런 문제가 없습니다.

    허깅 텍스트 필드의 top, leading, 컴프레션 레지스턴스 텍스트 필드의 traling, top( == hugging)을 잡아줬습니다. 

     

    이 상황에서 두 텍스트 필드 사이의 제약을 걸어주면 어떻게 될까요? 둘 사이의 제약을 10으로 주고 싶습니다. 

     

    이렇게 될 때 두 텍스트 필드는 각각 왼쪽 오른쪽으로 30만큼 떨어져있어야 하기 때문에 사이를 10으로 맞추려면 어느 한 쪽이 자신의 고유 크기를 포기해야 합니다. 이때 필요한 개념이 CHCR입니다. 살펴봤던 내용으로 추측해보면, 둘 중 하나가 자신의 크기를 포기하고 늘어나야하니까 Content Hugging Priority를 조절해줘야 할 것 같네요 :)

    하지만 현재 두 텍스트 필드는 기본 설정 값 250으로 동일합니다.

     

    Hugging이는 자신이 원래 크기보다 늘어나는 걸 용납할 수가 없습니다. 크기를 꽉 움켜쥐려고 합니다. Hugging이의 horizontal Priority를 251로 1을 더 키워서 도와줘보겠습니다. Hugging이의 Hugging Priority가 더 높기 때문에 더 낮은 compression resistence가 자신의 크기를 포기하고 더 늘어나게 되는 걸 확인할 수 있습니다.

     

    여기서 화가난 compression resistence가 자신의 text를 더 늘리면 어떻게 될까요? 
    이 경우엔 둘 중 하나가 자신의 크기를 포기하고 줄어들어야 합니다. 하지만 역시 기본값이 750으로 동일하기 때문에 누구 하나 양보하지 못하고 있습니다.

     

    이번엔 compression resistence를 도와줘 보겠습니다. compression resistence priority가 더 작은 hugging은 자신의 고유 크기를 포기하고 더 줄어들게 됩니다.

     

     

    오토레이아웃을 적절히 사용하다 보면 CHCR 없이도 개발이 가능하지만 점점 복잡해지는 UI를 만들다 보면 한번씩 사용해야 할 상황을 만나게 되는 것 같아요. CHCR의 개념을 단순히 늘어나고 줄어들고 정도의 개념으로 대강 이해하면 혼동이 올 수 있겠어요 @_@
    두 경우 모두 자신의 고유 크기를 지키기 위한 노력임을 이해하고 적절히 사용해야겠습니다 :)

    도움이 되셨으면 좋겠네요! 감사합니다.

     

     

    참고

    Auto Layout Guide: Apple Document

     

    'iOS' 카테고리의 다른 글

    RIBs) tutorial1  (0) 2021.06.25
    CALayer 그리고 View와의 관계  (0) 2021.01.31
    GCD, Dispatch  (0) 2021.01.19
    [개발자 문서읽기] UIApplicationMain(::::)  (0) 2021.01.16
    [개발자 문서읽기] Responding to the Launch of Your App  (0) 2021.01.16

    댓글

Designed by Tistory.