일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | |||||
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |
- drift
- DART
- Navigation
- textview
- android
- TEST
- livedata
- Coroutines
- LifeCycle
- Compose
- binding
- Dialog
- intent
- 안드로이드
- 앱바
- appbar
- viewmodel
- Flutter
- Button
- CustomScrollView
- textfield
- Kotlin
- data
- 계측
- activity
- 앱
- scroll
- tabbar
- ScrollView
- 테스트
- Today
- Total
Study Record
[Android] 앱 아키텍처 본문
우리가 주로 사용하는 핸드폰의 앱은 리소스가 제한되어 있어 새로운 앱 여러 개를 동시에 사용자에게 제공하기 어렵다. 따라서, 운영체제에서 새로운 앱을 위한 공간을 확보하도록 언제든지 일부 앱 프로세스를 종료시킬 수 있다. 또한, 앱을 시작하는 경로는 앱 런처 아이콘을 클릭하는 순간뿐만 아니라 타 앱에서 연결되어 시작될 수 있고 알림을 클릭하여 앱을 시작할 수 있다. 여러 곳에서 시작되는 것은 앱을 시작할 수 있는 앱의 구성 요소(Activity, Fragment, Service 등)가 있기 때문이다.
이 앱의 구성 요소는 개별적이고 비순차적으로 시작되고 운영체제에 의해서 언제든지 종료될 수 있기 때문에 앱 구성요소에 애플리케이션 데이터나 상태를 저장해서는 안되고 앱 구성요소가 서로 종속되면 안 된다.
앱 구성요소에 애플리케이션 데이터와 상태를 저장할 수 없다면, 앱을 어떻게 설계해야할지에 대해서는 Android 에서 권장하는 앱 아키텍처 가이드를 제시해 준다.
+ 앱은 데이터 모델(애플리케이션 데이터)에서 UI 를 도출해야 한다. 데이터 모델은 앱의 데이터를 나타내며 앱의 UI요소 및 기타 구성요소로부터 독립되어 있다. 즉, 데이터 모델은 앱 구성요소의 수명 주기와는 관련 없다.
😶 일반적인 아키텍처 원칙
관심사 분리
관심사 분리 디자인 원칙은 각각 별개의 책임이 있는 여러 함수 클래스로 앱을 나눠야 한다는 원칙이다.
모델(model)에서 UI만들기
모델은 앱의 데이터 처리를 담당하는 구성요소로 앱의 UI 요소 및 앱 구성요소와 독립되어 있으므로 앱의 수명 주기 및 관련 문제의 영향을 받지 않는다. 이러한 모델로부터 UI를 구성해야 한다는 원칙이다.
😶 권장 앱 아키텍처
일반적인 앱 아키텍처는 최소 두 가지 레이어가 포함된다. 바로, UI Layer 와 Data Layer 이다.
UI Layer 는 화면에 데이터를 표시하지만 데이터와는 무관하다.
Data Layer 는 앱 데이터를 저장하고, 가져오고, 노출한다.
UI Layer 와 Data Layer 사이에 두 계층 사이의 상호작용을 간소화하고 재사용하기 위해 Domain Layer 를 추가할 수 있다.
UI Layer
UI Layer 는 화면 데이터를 표시하는 역할을 가진다. 사용자가 버튼을 누르거나 검색으로 인해 데이터가 변경될 때마다 변경사항을 반영하도록 UI 가 업데이트되어야 한다.
UI 요소 & UI 상태
UI 레이어는 화면에 데이터를 렌더링 하는 UI 요소와 UI 상태가 있다. UI 요소는 화면에 표시되는 View 혹은 Android Compose 에 의해 빌드된다. 사용자가 화면을 통해 보는 항목을 UI 라고 한다면 UI 상태는 앱에서 사용자가 봐야 한다고 지정하는 항목이다.
예를 들어, 뉴스 기사 목록을 보여주는 화면이 있다면 사용자가 직접적으로 보이는 항목이 UI 요소이며 뉴스 기사 목록과 관련한 데이터 클래스(ex. NewsItemUiState)를 UI 상태라고 할 수 있다. UI 상태가 변경되면 UI 요소도 반영돼야 한다.
data class NewsItemUiState(
val title: String,
val body: String,
val bookmarked: Boolean = false,
...
)
상태 홀더
UI 상태와 UI 요소와 관련된 로직을 전부 단일 클래스(Ex. Activity, Fragment)에서 전부 관리하는 것은 코드가 점점 복잡해질 수 있다. 이에 UI 상태를 생성하는 역할을 담당하고 생성 작업에 필요한 로직을 포함하는 클래스가 등장했고 이를 상태 홀더라고 부른다. 즉, 상태 홀더는 데이터를 보유하고 UI에 노출하며 앱 로직을 처리하는 구성요소이다. 상태 홀더 중 하나인 ViewModel 은 Data Layer 에 액세스 할 권한이 있는 화면 수준 UI 상태를 관리하는 클래스이다.
이렇게 UI 상태가 아래로 향하고 사용자에 의해 버튼이 클릭되거나 터치됐을 때 등의 이벤트는 위로 향하는 패턴을 단방향 데이터 흐름(UDF)라고 부른다.
ViewModel
ViewModel 은 UI가 사용하는 상태를 보유하고 노출한다. UI 상태란 ViewModel 에 의해 변환된 애플리케이션 데이터이다. ViewModel 을 사용하면 앱이 모델에서 UI 만들기 아키텍처 원칙을 따르도록 할 수 있다. ViewModel 은 Android 프레임워크에서 Activity 가 소멸되고 다시 생성될 때 폐기되지 않은 앱 관련 데이터를 저장한다.
Data Layer
Data Layer 는 앱의 데이터 생성, 저장, 변경 방식을 결정하는 규칙이 포함된 비즈니스 로직을 포함한다. 앱에서 처리하는 다양한 유형의 데이터별로 저장소 클래스(Repository)를 만들어야 한다. 영화 관련 데이터는 MoviesRepository, 결제 관련 데이터는 PaymentsRepository 등을 예시로 들 수 있다.
'안드로이드' 카테고리의 다른 글
[안드로이드] DataSotre (SharedPreferences 대체) (0) | 2023.08.21 |
---|---|
[안드로이드] Repository pattern 과 Caching (0) | 2023.08.21 |
[안드로이드] Room (database) 살펴보기 (ViewModel, Flow, ListAdapter, LiveData, Coroutines) (0) | 2023.08.19 |
[안드로이드] RecyclerView ListAdapter 살펴보기 (0) | 2023.08.10 |
[안드로이드] binding Adapter (결합 어댑터) (0) | 2023.08.10 |