목적 : Android App 권장 Architecture를 이해하기
1. Android Developer 레퍼런스 문서
AAC에 대해서 문서로 남기기로 마음을 먹고 디벨로퍼 레퍼런스 문서를 보게 되었는데 아주 잘되어 있음을 느꼈습니다. 샘플소스도 엄청나게 많았고, 샘플소스만 보아도 벌써 앱 개발 한그릇 뚝딱 할 수 있을 것 같았습니다. 정말 Android는 참 친절하다고 생각합니다.
(사과나라는 불친절하다고 생각합니다...)
물론 레퍼런스 문서를 보면서 개인적인 의견에 대해 다른 사람들은 어떻게 생각하는지 어떤식으로 응용하는지에 대해 알아볼 때는 구글링을 통해 다른 사람들의 의견도 접하게 되었고 많이 배울 수 있었습니다.
다른 사람들도 이 글을 보게 되겠지만 사실 정답은 디벨로퍼 사이트에 있다고 생각하며 이 글을 올립니다.
아래는 정답을 향한 디벨로퍼 가이드 문서 링크입니다.
Android Developer Reference Guide
- Android Developer Jetpack
- Android Architecture Component
2. AAC란 무엇인가
1) AAC가 나온 이유
Android Architecture Component(이하 AAC)는 'Google I/O 2017'에서 처음 발표된 라이브러리 모음입니다.
구글에서 AAC를 제공한 이유는 Android를 구성하는 Component( Android, Service, BroadcastReceiver, ContentProvider 등)가 서로 다른 생명주기(lifeCycle)를 가지고 있으며, 이 들의 생명주기를 잘 연결할 뿐만 아니라 컴포넌트들을 서로 잘 연결하며, 더욱 손쉽게 앱을 개발해나가도록 가이드하기 위한 것이었습니다.
당시에는 라이브러리 묶음으로 AAC를 칭했지만, Android jetpack이 2018년 5월에 나오면서 AAC가 jetpack의 구성요소로 변경되었습니다.
그래도 AAC로 정의되어 있는 라이브러리들을 확인해본다면 레퍼런스 문서에 있는 항목들을 보면됩니다.
- DataStore - SharedPreferences 대신 사용할 key-value 저장소
- ViewBinding - XML 레이아웃 뷰결합 클래스
- DataBinding - 레이아웃의 UI 구성요소를 앱의 데이터 소스와 결합 제공
- Lifecycles - 수명 주기 인식 구성요소(Activity, Fragment 수명주기기반 동작을 자동 조정)를 빌드할 수 있는 클래스 및 인터페이스
- LiveData - 수명주기를 인식하는 관찬 가능한 데이터 홀더 클래스
- Paging3 - 데이터 페이지를 로드하고 표시
- ViewModel - 수명 주기를 고려한 UI 관련 데이터를 저장하고 관리하는 클래스
- WorkManager - 백그라운드 작업을 할 수 있게 해주는 라이브러리
위 항목이 Architecture Component 범주에 들어가 있습니다. 원래 AAC 범주로 알고 있던 Navigation, Room은 포함이 안되어 있네요.
아마 Jetpack 이후 한번 정리가 되서 AAC 라기 보다는 Jetpack 구성요소 중 Architecture 부분의 라이브러리들이 이러이러한 것이 있다라고 정의된 것 같습니다.
샘플코드도 너무나 잘되어 있으니 한번 보시는걸 추천드립니다.
2) Android Jetpack이란?
구글에서 AAC을 제공한 동기와 마찬가지로 개발자가 쉽고,빠르게,좋은 퀄리티의 앱을 개발하도록 라이브러리,도구,가이드 모음인 jetpack이 나오게 되었습니다.
Android Jetpack이라고 구글링하면 나오는 제일 유명한 이미지. Architecture 영역에 포함된 라이브러리 뿐만 아니라, 다양한 도구와 가이드를 제공합니다.
jetpack의 라이브러리는 기본적으로 androidx. 패키지로 제공이 됩니다. 제공하는 라이브러리 갯수도 정말 어마어마하게 많고 계속 실시간으로 더나은 버전으로 나오고 있습니다. 라이브러리 목록이 궁금하시면 아래 링크를 확인해보시면 됩니다.
jetpack의 라이브러리 버전은 안정화,알파,베타 버전이 있으며 잘 활용해서 사용을 해야 합니다.
3. Clean Architecture
1) Android와 Clean Architecture
Android 레퍼런스 문서를 참조해 보면, Clean Architecture를 도입해서 Guide를 하고 있습니다.
클린 아키텍처를 사용하는 이유에 대한 내용은 아래와 같습니다. (출처는 위 링크, 감사합니다 꾸벅)
- Clean Architecture는 프레임 워크에 독립적입니다.
- Clean Architecture는 일부 기능이 포함된 라이브러리 (곧 프레임워크)에 의존하지 않습니다.
- 이를 통해 프레임워크의 제약에 시스템을 맞추는 것이 아니라, 시스템의 도구로써 프레임워크를 활용할 수 있게 합니다.
- Clean Architecture는 테스트를 용이하게 해줍니다.
- The business rules(Entity)를 테스트하는데에 외부 요소를 필요로 하지 않습니다.
- Clean Architecture는 UI에 독립적입니다.
- 다른 시스템 변경 없이, UI를 쉽게 변경할 수 있습니다. (UI 변경의 용이성을 줍니다.)
- 예들 들면, 웹 UI에서 Console UI로 변경한다 할때, The business rules(Entity)를 변경없이 그대로 사용할 수 있습니다.
- Clean Architecture는 DB와 독립적입니다.
- The business rules(Entity)이 DB에 바인딩 되지 않으므로, DB의 종류를 쉽게 변경할 수 있습니다.
- 예를 들면, Oracle에서 SQL Server, for Mongo, BigTable, CouchDB 등등으로 쉽게 변경 가능합니다.
- Clean Architecture는 외부와 독립적입니다.
- The business rules(Entity)는 외부에 대해 알필요가 없고, 전혀 알지 못합니다.
- 이 덕분에 1-4의 이점을 가져올 수 있는 것입니다.
간단히 소개하자면 UI Layer(Presentation Layer), Domain Layer, Data Layer의 세가지 영역으로 class를 분리하고 각 영역의 종속항목을 관리하여 의존성을 주입(DI)하는 방식으로 아키텍처를 구조화하도록 하는 것입니다.
이 클린 아키텍처를 베이스로 Architecture를 만들도록 권장하고 있습니다. (권장하는 이유는 저 위에 내용 그대롭니다.)
2) Android MVVM
클린 아키텍처+MVVM 패턴이 적용된 아키텍처로 개발하도록 권장하고 있는데 jetpack 이미지만큼 유명한 이미지가 아래 다이어그램 표 입니다.
(1) 기존 MVVM 정의
Model, View, ViewModel로 패턴을 나눠 클래스간 연관성을 낮추고 유지보수를 용이하게 하는 아키텍처 패턴이며, 마틴 파울러(Martin Fowler)의 '프레젠테이션 모델 디자인 패턴'의 변형입니다.
1. View - UI에 관련된 항목. 사용자가 스크린을 통해서 보는 것들에 대한 구조, 레이아웃, 형태를 정의하는 것입니다. 뷰는 애니메이션 같은 UI 로직을 포함하되 비즈니스 로직을 포함하지 말아야 합니다.
2. ViewModel - 뷰 모델의 역할은 뷰가 사용할 메서드와 필드를 구현하고, 뷰에게 상태 변화를 알리는 것입니다. (뷰는 뷰 모델의 상태 변화를 옵저빙한다.) 뷰 모델에서 제공하는 메서드와 필드가 UI에서 제공할 기능을 정의합니다.
3. Model - 비즈니스 로직과 유효성 검사와 데이터를 포함하는 앱의 도메인 모델로 생각할 수 있습니다. 앱에서 사용할 데이터에 관련된 행위와 데이터를 다룹니다.
https://docs.microsoft.com/ko-kr/xamarin/xamarin-forms/enterprise-application-patterns/mvvm
해당 패턴으로 개발하게 되면 Clean Architecture가 추구하는 방향으로 구조화가 가능합니다.
(2) Android MVVM 정의
1. View - UI Layer(View,ViewModel)
- Activity, Fragment 등의 UI layout 구조를 작업하는 elements
2. ViewModel - UI Layer(View,ViewModel)
- ViewModel+LiveData
3. Model - Domain Layer(UseCase) + Data Layer(Repository, DataSource)
- UseCase는 선택사항
- Repository, DataSource 등 Data Layer를 이루는 항목들
(번외) MVVM ViewModel vs AAC ViewModel
MVVM 패턴의 ViewModel과 AAC의 ViewModel Class는 엄연히 다른 내용이며 이 내용에 대한 글들이 심심치 않게 올라온다.
결론은 AAC ViewModel 클래스 만으로는 ViewModel이 될 수 없으며 LiveData 등을 포함하여 어느정도 흉내를 낼 수 있다. 입니다.(AAC ViewModel은 생명주기를 길게 만들어 데이터를 보호하기 위한 용도임)
4. Android 권장 Architecture
1) 의존성 주입(Dependency Injection)
클린 아키텍처의 중요한 사항 중에 테스트를 용이하게, 의존성을 낮추는 것인데 수동으로 종속성을 넣을수도 있으며, 구글에서 제공하는 Dagger Hilt를 통해 종속성 주입을 할 수도 있습니다.
의존성 주입은 간단하게 말하면 A 클래스에서 B 클래스를 사용할 때 A 객체(인스턴스) 내부에서 B 객체를 새로 생성(인스턴스)해서 쓰는 것이 아니라 별개의 공간에서 B 객체를 생성한 후 A 객체에 넣어서 쓰도록 하는 것 입니다.
구글에서는 Dagger Hilt라는 플러그인을 제공하여 의존성 주입을 하도록 권장하고 있습니다.
@ 어노테이션을 통해 활성 항목과 지정항목들을 지정하며 사용하는 방식입니다.
2) Android 테스트
안드로이드 신규 프로젝트를 생성하면 기본적으로 같이 생성될정도로 안드로이드 개발에 있어서 중요한 항목입니다.
테스트는 범위와 동작의 크기에 따라 소형,중형,대형 카테고리로 분류가 되며, 카테고리 크기가 커질수록 비용이 커져서 적절히 분배하여 테스트를 하는 것을 권장합니다.
5. 결론
구글은 안드로이드 앱을 개발함에 있어서 권장하는 아키텍처를 정의하고, 그 아키텍처는 clean Architecture를 기반으로 MVVM 패턴과 라이프사이클, 의존성 주입, 테스트 등을 사용하는 것입니다.
해당 아키텍처를 잘 구조화하도록 여러 라이브러리(AAC)를 제공하며, 더 나아가 좋은 퀄리티의 앱을 쉽고 빠르게 개발하도록 개발자 등에 제트팩(jetpack)을 달아준 것 입니다.
안드로이드 개발자는 이 개념들을 잘 습득하고 잘 사용하는 것이 중요하다고 생각하며 글을 마치도록 하겠습니다.
