[AAC 배경]
- 안드로이드는 Activity,BroadcastReceiver,Service등 여러 컴포넌트들을 제공하는데, 이것들은 생명주기와 얽혀있다.
- 앱을 잘 만들기 위해서는 이러한 컴포넌트들을 부드럽게 동작하도록 해야하는데, 그러기 위해서는 생명주기/수명주기를 잘 학습해서 엉키지 않도록 해야했다. → 개발자의 몫
- 수명주기에 의해 생성되는 문제에 대한 '솔루션' 이 없었기 때문에 ,본인만의 솔루션을 만들거나 공식적인 지원이 없는 라이브러리등을 채택해서 개발을 해와야 했었다.
[AAC 등장]
- 그래서, 구글은 2017 Google I/O 에서 Android Application Architecture를 공식 권장사항으로 발표하고, 이를 구현할 컴포넌트들을 제공하기로 했다.
- 이것이 바로 AAC(Android Architecture Components) 이다.
[기본적으로 지켜야하는 아키텍처의 원칙 (Android Application Architecture)]
- 좋은 안드로이드 앱을 만들기 위한 안전한 방법 2가지 포인트를 제안한다.
<관심사 분리>
- 가장 중요한 원칙. 뷰와 모델의 분리가 되어야 한다. UI기반의 클래스는 UI 및 운영체제 상호작용을 처리하는 로직만 포함되어야 한다.
UI기반의 클래스를 최대한 가볍게 유지해야, 수많은 생명주기 문제를 피할 수 있다.
<모델에서 UI만들기>
- 모델에서 UI를 만들어야 한다. 모델은 앱의 데이터를 처리하는 구성요소로써, 앱의 뷰객체 및 앱 구성요소와는 독립되어 있으므로 생명주기 문제에 영향을 받지 않는다.
데이터 관리 책임이 잘 정의된 모델클래스(지속모델)를 기반으로 앱을 만드는것이 이상적이다.
[등장한 새로운 아키텍처]
- Room, ViewModel, LiveData, and Lifecycle 의 4가지 구성요소가 있다.
-
Lifecycle : 생명주기 모니터링을 돕는다. (Lifecycle Owner / Lifecycle Observer)
-
LiveData : 개선된 Observable, 생명주기와 데이터 변경을 감지. (onActive() / onInactive() : resume 또는 started 상태에서의 ovserver의 갯수를 확인)
-
ViewModel : 데이터를 생명주기와 분리하도록 도와줌. ViewModelProviders로 Scope를 관리하여, Scope내에서는 하나의 인스턴스만을 유지하여 작업이 중복되거나 소실되지 않도록 함.
-
Room : Annotation기반의 ORM(Object Relation Mapping) 라이브러리 중 하나
