[TIL] UIView? UIStackView! 설계 실수라고 하자.

Eden·4일 전
0

TIL

목록 보기
90/92
post-thumbnail

UIView 구현 ➡️ Label들을 UIStackView 넣어서 레이아웃을 조정하면 되겠다! ➡️ UIView와 UIStackView를 같은 역할로 동시에 사용 ➡️ ❓❓❓❓❓❓ ➡️ 그냥 UIStackView만 써도 되는데 어디서부터 잘못됐지??

아쉬운 점

이번 과제에서 UI 레이아웃을 구성할 때 UIView안에 UIStackView 담아서 사용했다. 쉽게 말하자면 UIView안에 레이아웃을 이유로 UIStackView를 넣었는데 알고보니 같은 역할을 하고 있었던 경우다.
하지만 작업이 진행되면서 UIStackView만으로 충분히 설계할 수 있었음을 깨달았다. 처음부터 스택뷰를 중심으로 설계했다면 코드 구조가 더 간결하고 유지보수하기 쉬웠을 것이다.


왜 처음부터 UIStackView로 구현해야 했을까

구조의 간결함

UIStackView는 내부 뷰를 정렬하고 배치하는 데 최적화된 컴포넌트다. 이 기능을 활용하면 별도의 제약 조건을 최소화하면서도 원하는 레이아웃을 쉽게 구성할 수 있다.

코드 중복 제거

UIView와 UIStackView를 섞어 사용하면 제약 조건 설정이 중복될 가능성이 높아진다. 스택뷰를 활용하면 addSubview 대신 addArrangedSubview로 모든 하위 뷰를 관리할 수 있다.

유지보수의 용이함

스택뷰 하나로 내부 요소를 정렬하면 레이아웃 변경 시 수정 범위가 줄어들고, 구조가 명확해져 협업에도 유리하다.


처음부터 구조에 대한 이해도를 가지고 시작했으면 좋았을 텐데, 그런 시간을 가지지 못해 어이없는 실수가 발생됐다ㅣ.

중첩된 구조는 나를 복잡하게 해요!

초기 설계에서는 상위 레이아웃 컨테이너로 UIView를 사용하고, 그 안에 여러 레이블과 스택뷰를 배치하는 구조를 계획했다. 그러나 이러한 접근 방식은 문제가 있었다.

여백 관리의 어려움

UIView와 스택뷰 사이의 여백을 설정하는 과정에서 중복된 제약 조건이 발생했다. 이로 인해 레이아웃 조정이 복잡해졌다.

비효율적인 구조

UIView가 단순히 레이아웃 컨테이너로만 사용되었고, UIStackView 하나로 대체할 수 있는 구조였다.


이러한 문제를 해결하기 위해 UIView를 제거하고, UIStackView 하나로 모든 하위 뷰를 관리하는 방식으로 변경했다. 이로써 중복된 제약 조건을 없애고, 보다 간결하고 효율적인 레이아웃을 구현할 수 있었다.


반성하자

레이아웃 설계 단계에서 계획하기

스택뷰는 배치와 정렬이 주된 레이아웃 요구사항일 때 가장 효과적인 도구다. 다음부터는 설계 단계에서 스택뷰로 가능한 부분을 먼저 고려해야겠다..

UI 요소의 중복 최소화

레이아웃 컨테이너를 불필요하게 겹치지 않도록 설계하고, 필요한 최소한의 요소로 효율적인 구조를 만들면 좋을 것 같다.

유지보수성을 염두에 둔 설계

코드의 가독성과 재사용성을 높이기 위해 중복된 레이아웃 구성이나 복잡한 제약 조건을 줄여야겠다.




그래도 이상한점을 깨닫고 UIStackView를 활용해 구현해냈다는게 중요한 것. 이번 경험은 다음 설계에서 더 나은 선택을 할 수 있는 밑거름이 되었다. 실수는 있었지만, 배웠다. 스택 +1

profile
Frontend🌐 and iOS

0개의 댓글