오토레이아웃

해당 뷰에 적용된 제약조건에 따라 뷰 계층 구조에 있는 모든 뷰의 크기와 위치를 동적으로 계산한다.

 

외부변경

SuperView의 크기나 모양이 변경되면 외부변경이 발생한다. 변경할 때마다 사용 가능한 공간을 최대한 활용하도록 레이아웃을 업데이트해야 한다.

 

내부변경

View의 크기 or UI 조작시 발생한다.

 

속성

SafeArea

애플리케이션이 상태바, 네비게이션바, 탭바 등을 가릴 수 없는 애플리케이션만의 영역이다.

iPhoneX에서부터 Notch(노치)가 생겨나며 생겨났다.

최대한 SafeArea를 이용해야 하며, SuperView를 사용하지 않는 편이 좋다. (동영상에서는 사용하는 것 같기는 한데, 가로모드와 세로모드의 차이때문인지 가이드가 다른 건지는 확실히 모르겠다...)

 

Constraint

뷰와 뷰 사이의 관계(하나의 뷰는 여러개의 뷰와 관계를 생성할 수 있다)를 정의하는 것이다.

위치는 방적식으로 나타낸다.

속성 설명
Width 너비
Height 높이
Top 상단
Bottom 하단
Baseline 텍스트 하단
Leading 텍스트 방향 시작
Trailing 텍스트 방향 끝
CenterX 수평 중심
CenterY 수직 중심

 

제약의 방정식 :

A.Leading = 1.0 * B.Trailing + 12.0 -> A의 Leading(텍스트방향의 시작위치)는 B의 Trailing(텍스트 방향의 끝위치)의 1.0배에 12.0을 더한 위치 -> (Interface Builder로 직접해보면 감이 쉽게 온다...)

 

Intrinsic Content Size

뷰가 원래 가지고 있었던 크기

 

Priority Constraint

제약 사이의 우선도

  • hugging Priority
    • 우선 순위(가로/세로)가 겹칠 때(정확한 판단이 어려울 때) 높은 우선순위의 Constraint를 적용
  • Compression Priority
    • 낮은 우선순위를 가진 제약(뷰)를 밀면서까지 높은 우선순위를 가진 제약을 지킴

Margin

레이아웃에 사용되는 간격

 

 

구현 방식

Programmatically

코드를 사용하여 AutoLayout을 적용한다.

iOS를 공부하는 초반에는 굉장히 어렵다. -> 내가 적용한 제약조건들이 적용되었을 때, 어떤 모양을 가질 지 상상이 가지 않기 때문

(분명 나는 사자를 그렸는데, 꼬리, 머리, 다리 위치가 뒤죽박죽인 상황...? 혹은 아예 없어지는 상황?)

 

하지만, 장점도 존재한다.

IB(Interface Builder)를 사용하는 것보다 훨씬 가독성이 좋아 협업에 적합하다.

-> IB로 제약사항을 작성 시, 변경/유지보수할 때, 하나하나 확인해야하며 굉장히 불편하다 즉, 자신 외에는 알아보는 데에 오래걸릴 수 있다.

(같은 View를 그리기 위해 다양한 방법이 존재하기 때문, 자신도 며칠 지나면 못 알아봄...)

BUT, 코드로 작성한다면, 누가 봐도 IB보다는 쉽고 빠르게 이해할 수 있을 것이다.

 

IB(Interface Builder)

XCode내에 내장된 IB를 사용하여 AutoLayout을 적용한다.

iOS를 공부하는 초반에 권장(이후에도 IB를 사용하여 개발을 진행한다고도 한다) -> 내가 적용한 제약조건들이 적용되는 것을 실시간으로 볼 수 있기 때문에, 보다 쉽게 View를 그릴 수 있다.

또한 IBOutlet, IBAction등을 사용하여 쉽게 UI Components와 Event를 동작/구현할 수 있음

 

 

+ Recent posts