- 최근 내가 구성한 클린 아키텍처의 레이어는 프레젠테이션 - 도메인 - 데이터 레이어로 구성된다. - 여기서 도메인이란 무엇일까? 바로 비즈니스 로직과 함께 앱의 핵심적인 규칙을 정의하는 레이어다. - UseCase가 포함되며 UseCase는 애플리케이션의 구체적인 비즈니스 규칙을 캡슐화한 것이다. - 앱의 기능적인 부분이 변경된다? 이 도메인 레이어를 수정하게 된다. - 여기서 기능을 명확히 보자1. 사용자에게 스켈레톤 효과를 보여준다.2. 사용자에게 유저 데이터 조건 처리를 통해 이벤트 목록을 추천한다.3. 사용자가 선택한 이벤트를 로컬 DB에 저장한다. - 1번의 경우에는 순수 UI 동작이다. 안쪽 레이어로 들어올 이유가 없다. - 3번의 경우에는 로컬 DB에 저장하는 순수 서비스의 기능이다. 데..
ViewModel
- 서비스의 기존 로직에 UI 로직과 DB 접근, 네트워크 로직을 복잡하게 모두 차지하고 있는 Manager 클래스가 있었다. - 작업 시에 혼동이 오고 유지보수다 어렵다 보니 에러 발생 시 찾기가 쉽지 않았고, 스레드에 대한 문제도 빈번하게 발생하고 있었다. - 어느 정도 간단한 DB 접근은 문제없다 해도 데이터가 많다면 ANR이 발생.. 이를 위해 비동기 처리가 누락된 부분을 탐색했지만 매니저 클래스를 나눠버리는 게 나을 것으로 확인되었다.- 아예 MVVM 패턴을 적용하도록 했다. 내부의 DB 쿼리 작업들이 명시된 ~DAO 클래스들은 내부적으로 AppContext를 사용하고 있는데, 이 의존성을 전부 해결하려면 상당한 시간이 걸려.. 일단은 당장 ANR 문제를 해결하기 위해 Hilt 없이 MVVM 패..
- 클린 아키텍처에서 UseCase는 단일 책임 원칙 하에 앱에서 실행되는 비즈니스 프로세스를 캡슐화하는 역할을 한다. - UseCase를 구성함으로써 ViewModel의 역할을 명확히 할 수 있고, UseCase는 변경을 최소화 한 채 관심사를 분리하고, Activity 뿐만 아니라 View, Widget에서 즉시 사용 가능한 이점도 있다. - 근데 사이드 프로젝트에서 UseCase를 구성하고 관리하다 보니.. UseCase의 역할이 단순히 전달 정도로 밖에 안 되는 부분들이 많았다.class GetDestinationUseCase( private val repo: SettingsRepository) { operator fun invoke(): Flow = repo.getDestination..
- 기존 내 서비스에서 구성되어 있던 API 호출 구조는 매번 Api Task Class를 만들어 Base를 통해 Retrofit 객체를 생성하고 호출하는 과정이었다.- 각종 초기화 및 고정 Header 값 추가 등의 코드가 난잡하게 구성되어 있어 가독성 및 관리에 좋지 않았다. - 의존성 자동 주입을 위해 Hilt와 이참에 MVVM 패턴까지 적용해 봤다.Network Module- 일단 기존에는 Api Task Class 내부에 매번 API 인터페이스를 다르게 생성했는데, 전반적인 모든 API func을 담을 ApiService를 구성했다.interface ApiService { @GET("api/test") suspend fun getTest( @Query("zoneId") z..
AAC(Android Architecture Components)란?AAC는 안드로이드 앱 개발을 쉽게 만들기 위해 제공되는 아키텍처 구성 요소앱 개발 시 라이프사이클 관리, 데이터 저장, UI 상태 관리 등을 표준화MVVM 패턴과 함께 사용하면 유지보수성과 확장성이 뛰어난 앱을 개발 가능AAC 주요 구성 요소ViewModel : UI 데이터를 저장하고 라이프사이클을 관리LiveData : 데이터 변경을 감지하고 UI에 반영Room : SQLite DB를 관리하는 ORM 라이브러리LifeCycle : Activity / Fragment의 라이프사이클을 관리ViewModel- UI 데이터를 관리하고 라이프사이클을 유지하는 역할- ViewModel을 사용하면 화면 회전 시 데이터가 유지됩니다.class My..
