android/nowinandroid 구조 파헤치기

이번 포스트에서는 Google Android팀의 nowinandroid가 어떻게 구성되어 있는지 살펴봅니다. 특히 Clean Architecture, Multi Module이 어떻게 적용되어 있는지를 중심으로 살펴보겠습니다.

 

Why nowinandroid?

시작하기에 앞서, nowinandroid(이하 'nia')는 Android팀에서 가장 활발하게 개발하고 있는 인기 있는 프로젝트입니다.

Google에서 Compose의 도입을 매우 권장하고 있고 이를 크게 밀어주고 있는 추세인데, nia는 이러한 Compose로만 개발한 앱입니다. 최신 아키텍처도 잘 담고 있어, 이 리포지토리만 공부해도 Clean Architecture, Multi Module, Compose라는 세 마리 토끼를 다 잡을 수 있다고 생각합니다.

 

Clean Architecture with Multi Module

nia는 구글의 앱 아키텍처 가이드라인을 따르고 있습니다.

이때 도메인 계층은 생략되어 있는 것을 알 수 있는데, 데이터 계층과 UI 계층 사이에 들어갈 정도의 로직이 없기 때문입니다. 반대로 서버로부터 데이터를 가져온 뒤 이 데이터를 재가공하는 복잡한 로직이 있는 프로젝트의 경우, 데이터 계층과 UI 계층 사이에 도메인 계층을 두어 해당 책임을 지게 할 수 있습니다.

 

또한 레이어 내의 자잘한 요소들에 대해서도 모듈을 따로 나눈 것을 알 수 있습니다.

 

아래 사진은 Topic과 연관된 클래스를 모듈과 레이어를 기준으로 구분한 사진입니다. 각 레이어 내 요소들이 어떤 책임을 지는지를 nia 앱 내의 여러 기능들 중 'Topic'을 기준으로 내용을 설명하겠습니다.

 

DataSource / Dao(core-network, core-database)

각각 네트워크와 앱 데이터베이스로부터 데이터를 가져옵니다.

 

Repository(core-data)

리포지토리에서는 기본적으로 로컬 데이터베이스에서의 데이터 플로우를 리턴하는 함수로 이루어져 있습니다.

그리고 앱 시작 시점에 네트워크 작업을 통해 데이터베이스의 값을 업데이트하게 됩니다. 네트워크 작업은 WorkManager를 통해 앱이 시작된 시점에 진행됩니다.

 

추가로 TopicsRepository 인터페이스는 Topic이라는 모델을 리턴해야 하는 반면, 하위 data source에서는 각각 NetworkTopic, TopicEntity라는 데이터 클래스를 리턴합니다. 따라서 Topic 모델로 변환하는 로직이 작성되어 있습니다.

 

ViewModel / Compose(feature-topic)

리포지토리로부터 Topic(Flow)을 가져온 뒤 TopicScreenUiState(Ui State)로 연결시킵니다. 뷰에서 UiState를 참조하여 뷰를 그려주게 됩니다.

 

Compose UI Dependency

Compose에 특화된 UI 의존성을 간략하게 설명하겠습니다.

1. NiaApp에서 NiaNavRail, NiaNavHost를 통해 Bottom Navigation을 표현하게 됩니다.

2. NavHost 내부에 forYouGraph, bookmarksGraph, interestsGraph를 두게 됩니다.

3. 각 feature의 Graph 내에서 Screen을 그려줍니다.

 

마무리

멀티모듈에서 각 모듈을 잘게 나누어둔 것이 프로젝트 개발을 더욱 유연하게 해주는 것처럼 느껴졌습니다.

이외에도 테스트 코드, 벤치마크, build-logic 등을 통한 라이브러리 의존성 관리와 같은 내용들에 대해서도 공부가 필요해보입니다.

 

추가

(22.12.12) nowinandroid에 아키텍처를 설명하는 md파일이 존재합니다.

https://github.com/android/nowinandroid/blob/main/docs/ArchitectureLearningJourney.md

 

https://github.com/android/nowinandroid/blob/main/docs/ModularizationLearningJourney.md