일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | ||||
4 | 5 | 6 | 7 | 8 | 9 | 10 |
11 | 12 | 13 | 14 | 15 | 16 | 17 |
18 | 19 | 20 | 21 | 22 | 23 | 24 |
25 | 26 | 27 | 28 | 29 | 30 | 31 |
- task cancel
- uikit toast
- custom ui
- RxSwift
- DP
- Tuist
- swift 점선
- rxdatasources
- swift dashed line
- claen architecture
- swift bottomsheet
- SWIFT
- swift navigationcontroller
- 타임라인 포맷팅
- swift custom ui
- button configuration
- scene delegate
- task cancellation
- custom navigation bar
- traits
- swift 백준
- BFS
- 버튼 피드백
- UIKit
- coordinator
- swift concurrency
- domain data
- reactorkit
- identifiable
- custombottomsheet
- Today
- Total
김경록의 앱 개발 여정
[Swift] 여러 상황에 대응하는 레이아웃 만들기(with SnapKit, update Layout) 본문
[Swift] 여러 상황에 대응하는 레이아웃 만들기(with SnapKit, update Layout)
Kim Roks 2025. 3. 8. 18:47개요
우리 디자인팀이 제작해 준 게시글 자세히 보기 화면은 기본 뼈대 자체는 완성되어 있었지만, 기획 검토 중 유저가 선택한 사진의 개수와 태그의 개수가 유동적이라는 점에서 놓친 부분이 있었습니다.
즉, 사진이나 태그가 전혀 없을 수도 있고, 일부만 있을 수도 있는 상황을 모두 고려해야 했습니다.
기존 80% 완성해놓은 뷰에 조건 별 제약 조건을 업데이트하는 과정을 글에 담았습니다.
시도해 본 방식은 아래와 같습니다.
1. 유저가 설정하지 않은 경우 해당 뷰의 높이를 0으로 지정하기
- 단순한 접근으로 사진과 태그 영역의 높이를 0으로 지정하는 방식으로 처리해봤는데, 이 경우 이미 설정된 Constraints가 그대로 유지되어 글과 소셜 버튼 사이에 불필요한 간격이 발생했습니다.
즉, 단순히 뷰의 높이만 0으로 만드는 방식은 제약 조건들이 그대로 남아있어 의도한 레이아웃을 구현할 수 없었습니다.
2. 스택뷰로 묶어서 처리하기
처음에는 이미지 파트와 태그 파트, 소셜 버튼 파트를 각각 UIStackView로 묶어,
유저가 선택하지 않은 경우 자동으로 해당 뷰를 제외하게 만드는 방식을 고민했습니다.
예를 들어, 스택뷰에 A(이미지)와 B(태그)가 있다면 A가 사라질 때 스택뷰가 자동으로 남은 공간을 채워주어, 다른 뷰들(글, 소셜 버튼)이 자연스럽게 상단으로 올라가게 할 수 있을 것 같았습니다.
하지만 실제 구현 과정에서 다음과 같은 문제가 발생했습니다:
- Nested StackView의 복잡도:
이미지와 태그 영역 각각의 스택뷰를 별도로 구성하다 보니, 각 스택뷰의 distribution 설정에 따라 둘 중 하나(예: 태그 영역)가 다른 쪽(이미지 영역)의 너비에 맞춰지는 현상이 있었습니다. - 레이아웃의 경우의 수 증가:
실제 상황은 다음과 같이 여러 케이스가 존재합니다.- Case 1: 이미지, 태그 모두 없는 경우
- Case 2: 이미지만 있는 경우
- Case 3: 태그만 있는 경우
- Case 4: 이미지와 태그 모두 있는 경우
- Case 5: 태그가 두 줄 이상으로 표현되는 경우
결과적으로, 스택뷰를 통한 해결 방식은 Constraints 관점에서는 성공적이었지만, 동적인 콘텐츠 개수에 따라 레이아웃을 세밀하게 제어하기에는 한계가 있었습니다.
3. SnapKit의 UpdateLayout를 활용하기 ⭐️
두 번째 방법은 SnapKit이 제공하는 updateConstraints와 remakeConstraints를 활용하는 것이었습니다.
이 중 remakeConstraints는 기존에 설정된 제약 조건을 모두 제거한 뒤, 새로운 제약 조건을 적용할 수 있는 메서드입니다.
remakeConstraints vs. updateConstraints
- updateConstraints: 기존 제약 조건 중 일부 값만 수정할 때 유용합니다. 기존 Constraint가 유지되기 때문에 간단한 값 변경에 적합하지만, 여러 제약 조건을 완전히 다시 정의할 필요가 있을 경우에는 한계가 있습니다.
- remakeConstraints: 기존 제약 조건을 모두 제거하고 새롭게 정의합니다. 이 과정은 약간 무거운 작업이지만, 동적인 레이아웃을 구성할 때 전체 구조를 재설정할 수 있어 복잡한 경우의 수를 가진 레이아웃에서 유리합니다.
저의 경우, 기존 설정된 제약조건에서 상단 제약 조건들만 조정하면 되므로 updateConstraints를 사용하기로 결정했습니다.
이 방식은 버튼이나 이미지, 태그 영역의 존재 여부에 따라 상단 제약 조건을 동적으로 재설정함으로써, 이미지와 태그가 없을 때 자연스럽게 다른 요소들이 위로 당겨지는 효과를 줍니다.
예를 들어, 이미지와 태그가 없는 경우에는 해당 영역의 상단 제약 조건을 컨텐츠 뷰의 상단 혹은 바로 이전 뷰와 연결하도록 재정의했습니다.
반면, 이미지나 태그가 있을 경우에는 그 뷰와의 간격을 유지하도록 제약 조건을 새로 만들어 적용했습니다.
결론
유저의 선택에 따라 뷰가 동적으로 변하는 상황에 대해
updateConstraints를 사용해 상단 제약 조건만 부분적으로 변경함으로써,
불필요한 간격 없이 자연스럽게 레이아웃을 조정할 수 있었습니다.
- updateConstraints는 전체 레이아웃을 재구성하는 remakeConstraints에 비해 성능 부담이 적고,
- 변경이 필요한 특정 제약 조건만 수정할 수 있기 때문에 유지보수에도 유리합니다.
특히 updateConstraints를 활용하며 가장 좋았던 점은
협업과정에 있어 다른 이에게 스택뷰의 동작을 예상시키는것보다, 코드 자체의 동작이 굉장히 직관적이게 보인단 점에 있었습니다.
'Trouble Shooting' 카테고리의 다른 글
[Swift UIKit] Custom Bottom Sheet (0) | 2025.04.11 |
---|---|
[Swift UIKit] 앱 전반에서 사용되는 Custom NavigationContoller (0) | 2025.04.11 |
[Swift] Launch Screen에 Asset.xcassets 이미지가 적용되지 않는다면 (0) | 2025.02.01 |
[Swift UIKit] 비회원은 못보는 TableView Section, 어떻게 할까? (0) | 2025.01.24 |
[Swift UIKit] 공백이 포함된 커스텀 뷰 구현기 (0) | 2025.01.10 |