[iOS 오토레이아웃 Views with Intrinsic Content Size] Dynamic Height Label and Text Field

[iOS 오토레이아웃 Views with Intrinsic Content Size] Dynamic Height Label and Text Field

전 글(2018/07/29 - [iOS] - [iOS 오토레이아웃 Views with Intrinsic Content Size] Simple Label and Text Field)에서는 textfield가 Safe area.top 기준으로 20으로 고정이었습니다. 이번에는 고정이 아닌 유동적으로 변하는 예제입니다. label의 font 크기를 키우면 text field의 제약조건이 커집니다. 반대도 마찬가지입니다. 하지만 두개 다 text를 다루고 있으므로 한 쪽을 키우면 다른 한쪽도 키우기 마련입니다. 따라서 예제 자체는 억지스러운 면이 있습니다. 이 예제는 text를 다루는 동적인 뷰와 이미지와 같은 고정뷰를 함께 사용할 때 빛을 발합니다

View and Constraints 

1. Name Label.leading = Safe Area.leading + 8

2. Name Text Field.Trailing = Safe Area.trailing + 8

3. Name Text Field.Leading = Name Label.Trailing + Standard

4. Name Label.Top >= Safe Area.Top + 20.0

5. Name Label.Top = Safe Area.Top + 20.0 (Priority 249)

6. Name Text Field.Top >= Safe Area.Top + 20.0

7. Name Text Field.Top = Safe Area.Top + 20.0 (Priority 249)

8. Name label.firstBaseline = Name Text Field.firstBaseline

Atrributes

초기값사용

Discussion

4,6번 제약조건에 의해서 최소값이 생겼습니다. 하지만 이들은 20보다 같을 수도 있고 클 수 있다라는 명확하지 제약조건입니다.  즉 Y축을 어디로 할지 애매하다는 것이죠 그래서 명확하게  5,7번을 추가로 주고 각 뷰의 content hugging보다 낮은 우선순위를 줬습니다. 혹여나 우선순위를 높게 하면 뷰가 늘어날 수 있기 때문입니다. 이는 특히 baseline을 사용할 때 주의해야할 부분입니다. 왜냐하면 text view를 사용하는 뷰들이 intrinsic content height를 유지해야지 baseline이 잘 적용되기 때문입니다. 

 예를 들어서 아래처럼 Name.top = Safe Area.top + 20 @ 252 처럼 Name label의 vertical content hugging priority 251보다 크게 하면 'Name.top = Safe Area.top + 20 @ 252'를 맞추기 위해서 Name Label의 height을 늘려서 baseline이 안 맞는 걸 볼 수 있습니다. 

'Name'이 baseline위에 약간 떠 있는 것을 볼 수 있다.

* content hugging 도 하나의 제약조건으로 생각하고 우선순위를 줄 때 고려해야겠습니다.

* 전 글 예제와 text size를 늘리면서 비교하면 좋을 것 같습니다.