lgvv98

Swift Concurrency를 적용하면서 발생한 동시성 문제사내에서도 동일한 이슈가 발생했었어서 해당 부분에 대해서 정리하고자 함.기존 Combine으로 작성된 코드를 async-await으로 교체하는 작업을 진행.  글의 순서Combine으로 작성된 코드 살펴보기Swift Concurrency로 단계적으로 전환하기Swift Concurrency로 안전성 확보하기Combine에서 Swift Concurrency 적용 Combine으로 작성된 코드 살펴보기기존 코드는 캐싱을 위해 캐시 프로퍼티가 존재하며, Combine을 기반으로 작성되어 있었음.Combine을 선택한 이유는 RxSwift가 익숙하여, RxSwift와 닮은 애플 퍼스트파티 선택에서 Combine을 선택   Swift Concurre..

UseCase와 Repository 테스트 목적 정리 이 포스팅은 현재 기준으로 내가 테스트 코드를 작성할 때 가지는 일종의 가이드라인. 성장하면서 바뀔 수도 있음. 글의 순서UseCase 테스트 목적Repository 테스트 목적Repository 테스트 하기SearchSubwayUseCaseTests 실패 후 로직 보완 안드로이드 공식 앱 아키텍처 가이드를 확인하면서 UseCase 영역에 해당하는 Domain이 Optional로 되어 있음을 확인할 수 있었음.개인 경험에 의하면 실제로 UseCase에서 특별한 처리 없이 사실상 래핑에만 해당하는 경우도 많긴 함. 일반적인 상황에서는 Domain Optional 이어도 나쁘지 않겠지만, 기능이 하나 둘 추가되면서 Repository가 두꺼워지고 결국은 ..

지하철 검색 기능에 캐싱 로직 도입하기 지하철 검색 로직에 캐싱 로직을 도입. 글의 순서SearchSubwayUseCase 개선SearchSubwayUseCase 테스트를 위한 Stub 객체 만들기SearchSubwayUseCaseTests 캐싱 로직 동작 검증 코드SearchSubwayUseCaseTests 실패 후 로직 보완  지하철 검색 로직은 사용자가 키보드를 통해 검색어를 입력할 때 throttle을 활용해 약간의 시간을 두어 검색을 실행.여기까지는 우리가 일반적으로 사용하는 검색 로직. 동일한 값에 대해 서버 요청을 줄이고, 동일한 결과값을 더 빨리 제공할 수 있으므로 이점은 확실. SearchSubwayUseCase 개선기존에 Combine을 활용해서 처리하고 있었는데, cache 프로퍼티..