모바일 앱 사용자 환경
일반적인 Android 앱에는 액티비티, 프래그먼트, 서비스, 콘텐트 프로바이더, 브로드캐스트 리시버를 비롯해 여러 앱 컴포넌트를 포함할 수 있고, 짧은 시간 내에 여러 앱과 상호작용할 때도 많다는 점을 고려하면, 앱은 사용자 중심의 다양한 워크플로에 맞게 조정될 수 있어야 합니다.
또한, 기기의 리소스는 제한적이므로 운영체제에서 새로운 앱을 위한 공간을 확보하기 위해 언제든 일부 앱 프로세스를 종료해야할 수 있습니다.
앱 컴포넌트는 개별적이고 비순차적으로 실행될 수 있으며, 운영체제나 사용자가 언제든지 앱 컴포넌트를 제거할 수 있습니다. 이런 이벤트는 직접 제어할 수 없기 때문에 앱 컴포넌트에 애플리케이션 데이터나 상태를 저장해서는 안되며 앱 컴포넌트가 서로 종속되면 안됩니다.
일반 아키텍처 원칙
Android 앱은 크기가 커지기 때문에 앱을 확장하고 견고성을 높이며 더 쉽게 테스트할 수 있도록 아키텍처를 정의하는 것이 중요합니다. 이를 위해 아래 원칙을 준수하도록 앱 아키텍처를 설계해야 합니다.
1. 관심사 분리
따라야 할 가장 중요한 원칙입니다. 액티비티 또는 프래그먼트에 모든 코드를 작성하는 실수는 흔히 일어납니다. 이러한 UI 기반의 클래스를 최대한 가볍게 유지하여 컴포넌트의 라이프사이클과 관련된 많은 문제를 피하고, 테스트 가능성을 개선할 수 있습니다.
또한, OS는 사용자 상호작용을 기반으로 또는 메모리 부족과 같은 시스템 조건으로 인해 언제든지 클래스를 제거할 수 있습니다. 만족스러운 사용자 환경과 수월한 앱 관리 환경을 제공하려면 이러한 클래스에 대한 의존성을 최소화하는 것이 좋습니다.
2. 데이터 모델에서 UI 도출하기
또 하나의 중요한 원칙은 데이터 모델에서 UI를 도출해야 한다는 것 입니다. 가급적 persistent models(ex Room, DataStore)를 사용하기를 권장합니다. 데이터 모델은 앱의 데이터를 나타냅니다. 데이터 모델은 앱의 UI 요소 및 기타 컴포넌트와 독립되어 있어 UI 및 앱 컴포넌트의 라이프 사이클과는 관련이 없습니다.
persistent models 사용이 이상적인 이유?
- Android OS에서 리소스를 확보하기 위해 앱을 제거해도 사용자 데이터가 삭제되지 않습니다.
- 네트워크 연결이 취약하거나 연결되어 있지 않아도 앱이 계속 작동합니다.
그렇다면 안드로이드 권장 앱 아키텍처는?
위에 언급한 일반적인 아키텍처 원칙을 고려하면 각 앱에서는 레이어가 두 개 이상 있어야 합니다.
1. 화면에 애플리케이션 데이터를 표시하는 UI 레이어
2. 앱의 비즈니스 로직을 포함하고 애플리케이션 데이터를 노출하는 데이터 레이어
UI와 데이터 레이어 간의 상호작용을 간소화하고 재사용하기 위한 도메인 레이어를 추가할 수 있습니다.
다이어그램의 화살표는 클래스 간의 종속 항목을 나타냅니다. 예를 들어 도메인 레이어는 데이터 레이어 클래스에 의존합니다.
UI 레이어
UI 레이어(또는 프레젠테이션 레이어)의 역할은 화면에 애플리케이션 데이터를 표시하는 것입니다. 사용자 상호작용(ex 버튼 누르기) 또는 외부 입력(ex 네트워크 응답)으로 인해 데이터가 변할 때마다 변경사항을 반영하도록 UI가 업데이트되어야 합니다.
UI 레이어는 다음 두 가지로 구성됩니다.
- 화면에 데이터를 렌더링하는 UI 요소. 이러한 요소는 뷰 또는 Jetpack Compose함수를 사용하여 빌드할 수 있습니다.
- 데이터를 보유하고 이를 UI에 노출하며 로직을 처리하는 State holders(ex ViewModel)
데이터 레이어
앱의 데이터 레이어에는 비즈니스 로직이 포함되어 있습니다. 비즈니스 로직은 앱에 가치를 부여하는 요소로, 앱의 데이터 생성, 저장, 변경 방식을 결정하는 규칙으로 구성됩니다.
데이터 레이어는 0개부터 여러 개의 데이터 소스들을 저장할 수 있는 각각의 리포지토리로 구성됩니다. 앱에서 처리하는 다양한 유형의 데이터마다 리포지토리 클래스를 만들어야 합니다. 예를 들어 영화 관련 데이터에는 MoviesRepository 클래스, 결제 관련 데이터에는 PaymentsRepository 클래스를 만들 수 있습니다.
리포지토리 클래스에서 담당하는 작업은 다음과 같습니다.
- 데이터 노출
- 데이터 변경사항을 한 곳에 집중
- 여러 데이터 소스 간의 충돌 해결
- 데이터 소스 추상화
- 비즈니스 로직 포함
각각의 데이터 소스 클래스는 파일, 네트워크 소스, 로컬 데이터베이스 같은 하나의 데이터 소스만 사용해야 합니다.
도메인 레이어
도메인 레이어는 UI 레이어와 데이터 레이어 사이에 있는 선택적 레이어입니다.
도메인 레이어는 복잡한 비즈니스 로직, 또는 여러 viewModel에서 재사용되는 간단한 비즈니스 로직의 캡슐화를 담당합니다.
예를 들어 여러 ViewModel에서 시간대를 사용하여 화면에 적절한 메시지를 표시하는 경우 앱에는 GetTimeZoneUseCase 클래스가 있을 수 있습니다.
컴포넌트 간 종속 항목 관리
앱의 클래스는 올바른 작동을 위해 다른 클래스에 종속될 수 있습니다. 특정 클래스의 종속 항목을 수집하는 데 다음 디자인 패턴 중 하나를 사용할 수 있습니다.
- 종속 항목 주입(DI) : 종속 항목 주입을 사용하면 클래스가 자신의 종속 항목을 구성할 필요 없이 종속 항목을 정의할 수 있습니다. 런타임 시 다른 클래스가 이 종속 항목을 제공해야 합니다.
- 서비스 로케이터 : 서비스 로케이터 패턴은 클래스가 자신의 종속 항목을 구성하는 대신 종속 항목을 가져올 수 있는 레지스트리를 제공합니다.
일반 권장사항
아래의 권장 사항은 필수는 아니지만, 장기적으로 더 강력하고, 테스트 및 유지관리가 쉬운 코드를 작성할 수 있습니다.
- 앱 컴포넌트에 데이터를 저장하지 않습니다.
각 앱 컴포넌트는 사용자와 기기의 상호작용 및 시스템의 전반적인 현재 상태에 따라 매우 단기간만 지속됩니다. - Android 클래스의 종속 항목을 줄입니다.
앱 컴포넌트는Context또는Toast같은 Android 프레임워크 SDK API를 사용하는 유일한 클래스여야 합니다. Android 클래스로부터 앱의 다른 클래스를 추상화하면 테스트 가능성은 높이고 앱 내의 커플링은 줄일 수 있습니다. - 앱의 다양한 모듈 간 책임이 잘 정의된 경계를 만듭니다.
예를 들어 네트워크에서 데이터를 로드하는 코드를 코드베이스의 여러 클래스나 패키지 전체에 분산하면 안 됩니다. 마찬가지로 데이터 캐시와 데이터 바인딩 등 여러 개의 관련 없는 책임을 동일한 클래스에 정의하면 안 됩니다. 권장 앱 아키텍처를 따르면 여기에 도움이 됩니다. - 다른 앱과 차별되도록 앱의 고유한 핵심에 초점을 맞춥니다.
반복적인 상용구는 Jetpack 라이브러리와 기타 권장 라이브러리가 처리하도록 하세요. - 앱의 각 부분을 독립적으로 테스트하는 방법을 고려합니다.
예를 들어 네트워크에서 데이터를 가져오기 위해 API를 잘 정의하면 해당 데이터를 로컬 데이터베이스에 보존하는 모듈을 더 쉽게 테스트할 수 있습니다. 그러지 않고 두 모듈의 로직을 한 위치에 혼합하거나, 네트워크 코드를 전체 코드에 분산하면 효과적인 테스트가 불가능하지는 않을지라도 훨씬 더 어려워집니다. - 가능한 관련성이 높은 최신 데이터를 보존합니다.
이렇게 하면 기기가 오프라인 모드일 때도 사용자가 앱의 기능을 이용할 수 있습니다. 모든 사용자가 끊김 없고 속도가 빠른 연결을 사용하지는 않는다는 점에 유의하세요. 끊김 없고 속도가 빠르더라도 혼잡한 곳에서는 수신 상태가 좋지 않을 수 있습니다.
