Droid Knights 팀에서 준비한 올어바웃 코틀린 (AAK: All About Kotlin) 행사에서 “Android Architecture Component on Kotlin”이라는 주제를 다룬 세션입니다.

---

소개

안드로이드 아키텍처 컴포넌트를 코틀린에서 사용하는 방법에 대해 소개하겠습니다. 저는 7년 차 Android 개발자이자 Google Developers Experts Android로 다우기술, 토스랩을 거쳐 이번에 싱가폴에 있는 Grab에 합류하는 정승욱입니다.

이번에 소개해 드릴 코드는 실무에서 한 번도 써본 적이 없고 안드로이드 아키텍처 컴포넌트를 이번 3월에 프리뷰로 미리 초청받아 보면서 어떻게 사용하면 좋을지 구상해본 내용입니다. 혹시 실무에서 사용하게 되면 사례를 공유해주시면 좋겠습니다.

이번 강연에서는 ViewModel, LiveData, Room 등의 안드로이드 아키텍처 컴포넌트와, Databinding, Dagger, MVVM 등 기존의 기술과 개념을 함께 살펴보겠습니다.

MVVM + Databinding + Dagger2

이미 공개된 내용이므로 안드로이드 아키텍처 컴포넌트의 기초에 대해서는 따로 설명하지 않고, MVVM, Databinding, Dagger2를 어떻게 함께 사용하면 좋을지부터 시작하겠습니다.

MVVM은 기본적으로 MS의 .NET에서 화면 구현을 위해 사용하는 기초 모델로, 위 그림은 MVVM 문서를 토대로 만든 다이어그램입니다. 프리젠터 영역에 뷰모델과 뷰가 있고, 도메인 영역에서는 엔티티나 리파지토리가 있는데 이런 MVVM에 Databinding과 Dagger2를 적용한 모습을 차례로 보여주고 있습니다. .NET에서는 UI를 작성하는 XML 부분에 뷰모델이라는 실제 코드에 접근할 수 있는 것을 만들어주는데 안드로이드에서도 유사한 형태로 Databinding을 만들어줄 수 있습니다. 컴포넌트 생성과 의존성 주입은 Dagger2를 사용합니다.

아키텍처 컴포넌트: Lifecycle + Room + LiveData

뷰모델에 해당하는 생명주기와 DB에 대한 Room, 데이터가 변경됐을 때 호출해주는 LiveData는 안드로이드의 경우 주로 액티비티나 프래그먼트와 연관됩니다.

뷰가 Lifecycle 콜백, 즉 LifecycleProvider를 이용해서 뷰모델에게 콜백을 하도록 진행할 예정이며, DB를 구성할 수 있는 Room로 리파지토리 영역에 접근할 수 있는 데이터베이스를 구성할 예정입니다. 또한, DB에서 변경된 데이터를 LiveData를 이용해서 뷰모델로 알릴 수 있도록 구성합니다. 중간에 LiveData를 모니터링하는 곳에서 데이터가 변경되면 뷰모델로 바로 전달할 수 있도록 진행할 예정입니다.

미리 알아둬야 할 개념들이 많으므로 처음 만나는 분께는 어려운 주제가 될 수 있으므로 코드와 함께 설명하겠습니다. 전체 코드는 GitHub에서 볼 수 있습니다.

데모

상단의 비디오 재생 버튼을 누르면 7:48 시점부터 데모를 볼 수 있습니다. 자세한 코드 설명이 있으니 꼭 영상을 시청해주세요.

모델 정리

모델에 대해 다시 설명하자면, XML에서 코드를 정의할 때 어떤 뷰모델과 뷰에 사용할 것인지 접근하고, 안드로이드 Databinding에서 자동으로 코드를 생성해주고, 뷰모델에서 데이터를 갖고 있다가 변경되면 뷰에 전달해줍니다. 이 역시 Databinding에서 모니터링하다가 업데이트하는 방식입니다. 뷰모델에서 사용하는 데이터는 Room에서 필요한 데이터를 가져와서 지정하고, DB가 변경되면 앞서 말했듯 그대로 뷰모델에 데이터가 전달되고 뷰모델이 이 데이터를 다시 뷰로 전달합니다. 이런 부분을 Databinding과 아키텍처 컴포넌트에서 제공하는 생성된 코드들이 지원해줍니다. 필요한 컴포넌트 인젝션은 Dagger2를 이용합니다.

모델의 장점

이런 모델을 사용하게 되면 뷰와 뷰모델이 서로의 존재를 알 필요가 없으며 Databinding에서 생성한 코드들이 알아서 서로를 모니터링해주므로 Databinding을 이용해서 제어할 수 있습니다.

생명주기 처리도 아키텍처 컴포넌트를 통하므로 initialize-finalize 호출을 할 필요 없이 옵저버블을 등록하면 되며, 필요한 동작은 어노테이션으로 간단하게 제어할 수 있도록 지원합니다. 따라서 안드로이드 프레임워크에 대한 뷰모델의 의존성이 낮아지고 유닛 테스트가 쉬워집니다.

데이터베이스 변경 역시 별도의 콜백을 지정하지 않고 LiveData에 의한 자동 변경 알림이 가능하므로 Lifecycle-awareness로 인해 필요한 동작만 수행할 수 있습니다. onResume, onStart, onCreate 등에 화면 갱신을 하거나 onDestroy에서 메모리를 해제해주는 등의 기본적인 동작만 해주면 되는 편리한 구조입니다.

모델의 단점

Dagger2, Databinding, MVVM, Architecture Component(Room, LiveData, Lifecycle Provider & Observer), RxJava, Reactive 등 알아야 할 점이 매우 많으므로 학습 곡선이 매우 가파릅니다. 특히 아키텍처 컴포넌트 내부 코드는 구글이 내부에서 만드는 아게라 코드가 많이 포함되므로 내부 동작을 이해하려면 Reactive 개념을 많이 공부해야 합니다.

또한, Lifecycle-awareness for RxJava가 지원되지 않으므로 따로 제가 만든 코드나 RxLifecycle-component를 사용해야 합니다. (ReactiveStreams는 JDK 9에 추가되는 컴포넌트만 지원하고 있으므로 이슈 리포팅을 해놓은 상태입니다.)

결론

구글에 안드로이드 아키텍처 컴포넌트를 왜 사용해야 하는지 질문했을 때, MVM, MVVM 등 수많은 선택 중 아키텍처 컴포넌트도 선택할 수 있도록 선택지를 늘리기 위해 나왔다고 했습니다. 안드로이드 아키텍처 컴포넌트가 여러분의 선택에 도움이 되길 바랍니다.

---

본 영상과 글은 올어바웃 코틀린 (AAK: All About Kotlin)의 비디오 스폰서인 Realm에서 제공합니다. 모바일 개발자가 더 나은 앱을 더 빠르게 만들도록 돕는 Realm 모바일 데이터베이스와 Realm 모바일 플랫폼을 통해 핵심 로직에 집중하고 개발 효율을 높여 보세요! 공식 문서에서 단 몇 분 만에 시작할 수 있습니다. 또한 Realm 아카데미에서는 모바일 개발자를 위한 다양한 최신 기술 뉴스와 튜토리얼을 제공하고 있으니 즐겨찾기하고 자주 들러 주세요!