프로젝트 (13) 썸네일형 리스트형 ViewModel 도입 - ViewController의 복잡도 개선 MVC 패턴을 사용하면서 ViewController의 복잡도가 점점 증가하는 문제가 발생했다.UI 업데이트, 데이터 로딩, 네비게이션 처리 등의 로직이 하나의 ViewController에 집중되면서, 코드 가독성이 저하되고 유지보수가 어려워지는 상황이 발생했다.이 문제를 해결하기 위해 MVVM 아키텍처를 도입하고, Input/Output 패턴을 적용하여 데이터 흐름을 개선하였다. 1️⃣ 문제: ViewController가 점점 비대해지는 문제 발생프로젝트 초반에는 MVC 패턴을 적용하여 UI와 로직을 분리하려 했지만, 기능이 추가될수록 ViewController의 역할이 과도해지는 문제가 발생했다.특히, 다음과 같은 문제들이 유지보수를 어렵게 만들었다.ViewController 내부에서 UI 이벤트 관리.. 테이블뷰 셀에서 의도치 않게 뷰가 늘어나는 문제 해결 과정 UITableViewCell의 특정 요소가 의도치 않게 크기가 늘어나며 레이아웃이 깨지는 문제가 발생했다.레이아웃을 유지하려고 했던 요소들이 밀려나고, 전체적인 UI가 어긋나는 현상이 나타났다. 1️⃣ 문제 정의: 늘어나서는 안 되는 뷰가 늘어나는 상황테이블뷰 셀 내부의 주요 요소는 다음과 같은 구조로 배치titleLabel → 왼쪽 상단에서 텍스트를 표시optionLabel → 왼쪽 하단에서 추가 정보를 표시countLabel → 오른쪽에서 개수를 나타냄forwardImageView → 오른쪽 끝에서 이동을 의미하는 화살표 아이콘 표시 💥 문제 발생:countLabel이 의도치 않게 늘어나면서 titleLabel과 optionLabel의 레이아웃이 깨짐forwardImageView와 countLabe.. UIKit 기반 프로젝트에서 Clean Architecture + MVVM-C 설계 UIKit 기반 프로젝트에서 MVVM 아키텍처를 활용하면서 ViewModel이 점점 비대해지는 문제와 ViewController에서 직접 화면 전환을 수행하는 비효율적인 구조를 경험했다.이러한 문제를 해결하기 위해 Clean Architecture를 적용하여 역할을 명확히 분리하고, Coordinator 패턴을 도입하여 화면 전환을 보다 효율적으로 관리하는 방식으로 설계를 개선하였다. 이 글에서는 MVVM-C 패턴과 Clean Architecture를 결합하여 설계한 과정과 고려한 점을 공유하고자 한다. 1️⃣ 기존 MVVM 아키텍처에서의 문제점ViewModel의 점진적 비대화 문제기능과 로직이 추가될수록 ViewModel이 점점 커지면서 여러 역할을 동시에 담당ViewModel이 비즈니스 로직 처리, .. SwiftUI에서 DIContainer를 활용한 의존성 주입(Dependency Injection) SwiftUI로 Film-in 프로젝트를 의존성 주입(DI, Dependency Injection)을 어떻게 구현할 지 고민하게 되었다.특히, UIKit과는 달리 SwiftUI에서는 @StateObject, @ObservedObject, @EnvironmentObject 등을 활용해상태관리를 해야 했기에 의존성 주입을 어떻게 구현할 지에 대해 고려가 필요했다. 처음에는 SOLID 원칙을 준수하면서 유지보수성을 높이는 방향으로 설계를 진행했지만, SwiftUI의 제약으로 인해설계의 변경이 필요했다. 이 글에서는 DIContainer 설계 과정에서 고려했던 사항과 결론을 공유하고자 한다. 1️⃣ UIKit에서 적용했던 의존성 주입 적용 방식최근 Clean Architecture를 적용했던 UIKit 프로젝트.. Secure Enclave와 Keychain을 활용한 Refresh Token 보안 관리 내 프로젝트에서는 서버 API(게시물, 팔로우, 좋아요 등)를호출하기 위해 Access Token을 사용하고 있다.하지만 Access Token의 유효시간이 5분으로 매우 짧아,사용자가 반복적으로 로그아웃되는 불편함을 경험했다. 1️⃣ 발생한 문제1. Access Token 만료 시 재로그인 요청사용자가 매번 직접 로그인해야 하므로 사용성 저하2. 자동 로그인 구현 시 보안 문제UserDefaults에 아이디 / 비밀번호를 저장하는 방식암호화되지 않은 민감한 정보 노출 가능성 2️⃣ 접근 방식고민했던 접근 방식은 2가지였는데 1. Access Token 만료 시 마다 재로그인✅ 보안 강점: 사용자가 직접 재로그인❌ 사용성 저하: 사용자가 매번 로그인해야 함2. Refresh Token을 활용한 자동 갱신.. Unit Test - Mock 객체 메서드 내 분기처리 내가 진행하고있는 LookForRealBurger 프로젝트비즈니스 로직의 데이터 흐름에 대한 신뢰성 향상을 위해 Unit Test를 진행했다. ViewController의 Input / Output 액션을 담당하는 ViewModel에비즈니스 로직을 담당하는 UseCase 객체를 테스트용 Mock 객체로구현하여 의존성을 주입 후, 테스트를 진행하도록 설계했다. 1️⃣ 성공 / 실패 분기처리 어떻게 하지...?하지만 테스트를 구현하려고 하니 문제가 발생하였는데,Protocol에 요구된 메서드를 통해 Mock 데이터를 활용하여 API 요청에 대한 테스트를 진행하기에매개변수로는 성공과 실패 케이스에 대한 분기 처리를 할 수 없어 테스트 코드를 구현하기에어려운 상황에 직면했다.이 상황에서 메서드와 로직을 재설계 .. ViewController의 Lifecycle과 Modal Present 이슈 개발을 진행하면서 TabBarController의 특정 탭에서 WriteViewController를present() 방식으로 모달 띄우는 과정에서 Xcode 경고 메시지가 발생한 경험이 있었다. 이 글에서는 경고 메시지의 원인, 생명주기의 중요성, 그리고 해결 과정을 다뤄보려고한다.1️⃣ 문제TabBarController의 두 번째 탭 선택.EmptyViewController가 로드됨.EmptyViewController가 로드되자마자 WriteViewController를 present()로 모달 띄움.발생한 Xcode 경고 메시지Presenting view controller from detached view controller is not supported, and may result in inco.. Pull To Refresh - 당겨서 새로고침 UX 개선 전체 리뷰 게시글을 확인하는 화면에서 Pull To Refresh 기능을 구현하던 중RefreshControl이 너무 빠르게 사라져 사용성이 불편했던 문제를 개선하였다.1️⃣ 문제: 어색하고 답답한 Pull To Refresh 개발자이자 사용자의 입장에서 테스트를 진행하면서 당겨서 새로고침 후 RefreshControl이너무 빠르게 사라져 데이터가 새로고침 되었는지에 대한 여부를 인지하기 어려웠다.새로고침 완료 피드백 부족: 사용자가 데이터 갱신 완료를 인지할 수 없음시각적 피드백 미흡: RefreshControl이 너무 빠르게 사라짐 2️⃣ 문제 분석: 왜 그러는걸까?문제의 원인은 코드 로직이었다.1차 구현데이터를 FETCH 요청 직후, endRefreshing()을 호출했기 때문에,데이터가 아직 로.. 이전 1 2 다음
