IOS App Programming/트러블 슈팅9 클린 아키텍쳐 TestCode 분리하기 문제 상황프로젝트를 진행하면서 팀원들의 개발 일정 상 앱의 디자인을 어느 정도 진행 된 뒤 API 연결에 들어가게 되었다.그러다 보니 연결이 제대로 되었는지, 데이터는 제대로 받아오는지 확인하기 위해 클린아키텍처 구조 상 DataSource (API 연결부)부터 Repository, UseCase를 지나 Presentation 레이어의 뷰모델, 뷰 까지 모두 연결되어야지만 테스팅이 가능했다.그런데 이 때, 앱의 구현이 진행됨에 따라 프레젠테이션 레이어 연결 시 변경해줘야 하는 부분들이 점차 늘어났고, 테스팅 실패 시 최악의 경우 전체 구조를 변경해야 하는 경우도 있었다.따라서 이 부분에서 불편함을 느껴 단계별로 DataSource 의 API 테스트, Repository의 DTO -> Entity 변환 테.. 2024. 8. 23. [iOS/Clean Architecture + ReactorKit] 클린아키텍쳐 책임 분리 ReactorKit을 사용하여 MVVM 모델로 구현을 하고 있었으며 클린아키텍처 구조로 프로젝트를 구성하고 있었다.프로젝트의 전체적인 구조를 살펴보면 다음과 같다Presentation ㄴ View(ViewController) ㄴ ViewModel(Reactor)Domain ㄴ Model ㄴ Usecase ㄴ Repository (프로토콜)Data ㄴ DTO Model ㄴ RepositoryImpl (구현부) ㄴ Datasource 로그인 로직을 구현하면서 여러 데이터 소스들을 사용하고 합치는 과정들을 거치게 되었고,이때 점점 레이어나 각 구성 요소들의 책임들을 모호하게 코드를 작성하고 있다는 생각이 들어 명확하게 책임 분리를 정리해야겠다고 생각했다.처음에 공부.. 2024. 8. 6. [iOS/ UIKit] Error 핸들링 - 모든 에러를 하나의 형식으로 관리하자 feat.ReactorKit ReactorKit을 사용하면서 state에서 Error를 받고 있었고 여러 UseCase에서 다양한 Error들을 내뱉는데 어떻게 관리를 해야 할까 고민이 있었다.한 개의 에러에 모든 에러를 몰아 넣을 수 없었다. 또한 NSError로 모두 정의하기에는 코드가 너무 지저분해 보였다.각 클래스마다 에러를 지정하고 싶었고, 내가 정의하지 못한 시스템 에러 또한 잡아주기를 원했다.그리고 각 에러마다 StatusCode와 간단한 설명이 있으면 좋겠다고 생각했다.따라서 각 클래스마다 LocalizedError 프로토콜을 준수하는 에러 값들을 만들고 statusCode와 errorDescription을 따로 선언해 주었다.예를 들면 다음과 같다 enum NaverLoginError: LocalizedError {.. 2024. 8. 2. [Project / 협업] Product Language 정립하기 프로젝트 초기 단계에서 앱을 기획을 점검하는 도중 AOS와 iOS 간의 의사소통에서 같은 컴포넌트라도 서로 지칭하는 언어가 달라"아 그게 ㅇㅇㅇ을 말하는 거죠?"라는 질문을 하는 일이 많았다.디자이너 또한 지칭하는 언어가 다르기 때문에 이에 대해 앱에 사용될만한 모든 컴포넌트들에 대해 정리를 해두고 디자이너분의 합류와 동시에 Product Language를 정립하기 시작했다. 예를 들어 iOS의 네비게이션바의 경우 AOS에서는 AppBar라고 불리며 오히려 하단 탭바를 네비게이션이라고 불렀고, 디자이너의 경우 화면 전환을 전반적으로 이르는 말을 네비게이션이라고 하였다.토스트 메시지나, 스낵바 등 iOS는 없지만 AOS에만 있는 컴포넌츠의 경우 AOS의 언어를 따라가면 괜찮았지만 위처럼 같은 컴포넌츠지만 .. 2024. 7. 28. 이전 1 2 3 다음
