1. Android Jetpack이란?
Jetpack은 2018년 구글 IO 행사에서 발표됬습니다. 안드로이드 공식 사이트를 들어가면 Jetpack 에 대한 설명을 볼 수 있습니다. 즉, 안드로이드에서 코드 작성을 더 편리하게 해주기 위해 직접 관리하고 있는 라이브러리 모음이라고 볼 수 있습니다.
2. AAC (Android Architecture Components)란?
아래의 초록색 Jetpack 4개의 섹션 중 하나로 구글에서 권장하는 방식으로 앱을 디자인하도록 돕는 라이브러리 입니다.
-
1. DataBinding
프로그래매틱 방식이 아니라 선언적 형식으로 레이아웃의 UI 구성요소를 앱의 데이터 소스와 결합할 수 있는 지원 라이브러리입니다.
-
2. Lifecycle
Lifecycle-aware components는 액티비티와 프래그먼트 같은 다른 구성요소의 수명 주기 상태 변경에 따라 작업을 실행합니다. 이러한 components를 사용하면 잘 구성된 경량의 코드를 만들고 더욱 쉽게 유지할 수 있습니다.
일반적인 패턴은 액티비티와 프래그먼트의 수명 주기 메서드에 종속 구성요소의 작업을 구현합니다. 하지만 이 패턴으로 인해 코드 구성이 나빠지고 오류가 증가하게 됩니다. Lifecycle-aware components를 사용하면, 수명 주기 메서드에서 components 자체로 종속 구성요소의 코드를 옮길 수 있습니다.
androidx.lifecycle 패키지는 Lifecycle-aware components(액티비티나 프래그먼트의 현재 수명 주기 상태를 기반으로 동작을 자동 조정할 수 있는 구성요소)를 빌드할 수 있는 클래스 및 인터페이스를 제공합니다.
-
3. Livedata
라이브 데이터는 LifeCycle을 인식할 수 있는 관찰가능한 데이터 홀더 클래스 입니다. 이것을 사용하여 기본 데이터베이스가 변경되면 뷰에 알리는 데이터 객체를 빌드합니다.
-
4. Navigation
사용자가 앱 내의 여러 콘텐츠를 navigation(탐색)하고, 그곳에 들어갔다 나올 수 있게 하는 상호작용을 의미합니다. Android Jetpack의 Navigation component는 단순한 버튼 클릭해서 좀 더 복잡한 패턴(앱바, 탐색 창)에 이르기까지 여러 가지 탐색을 구현하도록 도와줍니다. 탐색 구성요소는 기존의 원칙을 준수하여 일관적이고 예측 가능한 사용자 환경을 보장합니다.
-
5. Paging
페이징 라이브러리를 사용하면 로컬 저장소에서나 네트워크를 통해 대규모 데이터 세트의 데이터 페이지를 로드하고 표시할 수 있습니다. 이 방식을 사용하면 앱에서 네트워크 대역폭과 시스템 리소스를 모두 더 효율적으로 사용할 수 있습니다. 페이징 라이브러리의 구성요소는 권장 Android 앱 아키텍처에 맞게 설계되었으며 다른 Jetpack 구성요소와 원활하게 통합되고 최고 수준으로 Kotlin을 지원합니다.
-
6. Room
SQLite 개체 매핑 라이브러리입니다. 이것을 사용하여 상용구 코드를 피하고 SQLite 테이블 데이터를 자바 객체로 쉽게 변환할 수 있습니다. Room은 SQLite 문의 컴파일 시간 확인을 제공하며 RxJava, Flowable, LiveData observable을 반환할 수 있습니다.
-
7. ViewModel
ViewModel 클래스는 수명 주기를 고려하여 UI 관련 데이터를 저장하고 관리하도록 설계되었습니다. ViewModel 클래스를 사용하면 화면 회전과 같이 구성을 변경할 때도 데이터를 유지할 수 있습니다.
-
8. WorkManager
WorkManager는 지속적인 작업에 권장되는 솔루션입니다. 앱이 다시 시작되거나 시스템이 재부팅될 때 작업이 예약된 채로 남아 있으면 그 작업은 유지됩니다. 대부분의 백그라운드 처리는 지속적인 작업을 통해 가장 잘 처리되므로 WorkManager는 백그라운드 처리에 권장하는 기본 API입니다.
3. 구글에서 권장하는 앱 디자인
아래의 그림과 같이 Model ViewModel View를 나눠서 계층적으로 아키텍처를 구성하는 것을 알 수 있습니다. 아래 그림에 대한 내용은 깊이 들어가면 설명할 것이 많기 때문에 실제 포트폴리오 프로젝트와 곁들여서 클린 아키텍쳐를 주제로 하는 글에서 자세히 또 다뤄보겠습니다.
일반 권장사항
- 1. App components에 데이터를 저장하지 않습니다.
Activity, Service, broadcast receiver와 같은 앱의 진입점을 데이터 소스로 지정하지 않습니다. 대신 그 진입점과 관련된 데이터 일부만 가져오도록 other components에 맞춰 조정해야 합니다. 각 App component는 사용자와 기기의 상호작용 및 시스템의 전반적인 현재 상태에 따라 단기간만 지속됩니다.
- 2. Android 클래스의 종속 항목을 줄입니다.
앱 구성요소는 Context 또는 Toast 같은 Android 프레임워크 SDK API를 사용하는 유일한 클래스여야 합니다. 앱 구성요소와 별도로 앱의 다른 클래스를 추상화하면 테스트 가능성은 높이고 앱 내의 커플링은 줄일 수 있습니다.
- 3. 앱의 다양한 모듈 간 책임이 잘 정의된 경계를 만듭니다.
예를 들어 네트워크에서 데이터를 로드하는 코드를 코드베이스의 여러 클래스나 패키지 전체에 분산하면 안 됩니다. 마찬가지로 데이터 캐시와 데이터 결합 등 여러 개의 관련 없는 책임을 동일한 클래스에 정의하면 안 됩니다. 권장 앱 아키텍처를 따르면 여기에 도움이 됩니다.
- 4. 각 모듈에서 가능하면 적게 노출합니다.
예를 들어 모듈의 내부 구현 세부정보를 노출하는 단축키를 만들어서는 안 됩니다. 단기적으로는 약간의 시간을 벌 수 있지만, 코드베이스가 발전함에 따라 기술적 문제가 여러 번 발생할 수 있습니다.
- 5. 다른 앱과 차별되도록 앱의 고유한 핵심에 초점을 맞춥니다.
동일한 상용구 코드를 반복하여 작성하느라 시간을 낭비하지 마세요. 대신 앱을 독특하게 만드는 데 시간과 에너지를 집중하고 반복적인 상용구는 Jetpack 라이브러리와 기타 권장 라이브러리가 처리하도록 하세요.
- 6. 앱의 각 부분을 독립적으로 테스트하는 방법을 고려합니다.
예를 들어 네트워크에서 데이터를 가져오기 위해 API를 잘 정의하면 해당 데이터를 로컬 데이터베이스에 보존하는 모듈을 더 쉽게 테스트할 수 있습니다. 그러지 않고 두 모듈의 로직을 한 위치에 혼합하거나, 네트워크 코드를 전체 코드베이스에 분산하면 효과적인 테스트가 불가능하지는 않을지라도 훨씬 더 어려워집니다.
- 7. 가능한 한 관련성이 높은 최신 데이터를 보존합니다.
이렇게 하면 기기가 오프라인 모드일 때도 사용자가 앱의 기능을 이용할 수 있습니다. 모든 사용자가 끊김 없고 속도가 빠른 연결을 사용하지는 않는다는 점에 유의하세요. 끊김 없고 속도가 빠르더라도 혼잡한 곳에서는 수신 상태가 좋지 않을 수 있습니다.
4. reference
https://developer.android.com/training/dependency-injection/manual?hl=ko
https://developer.android.com/topic/architecture#common-principles
https://developer.android.com/topic/libraries/architecture
https://developer.android.com/jetpack/androidx
https://developer.android.com/jetpack
https://android-developers.googleblog.com/2018/05/use-android-jetpack-to-accelerate-your.html
https://developer.android.com/topic/libraries/architecture/lifecycle
https://developer.android.com/topic/libraries/architecture/paging/v3-overview?hl=ko
