[Clean Architecture] 03-안드로이드 권장 애플리케이션 설계 원칙

4. 안드로이드의 특징

• 일반적인 애플리케이션
  • 하나의 진입점을 가지고, 하나의 프로세스에서 실행
• 안드로이드 애플리케이션
  • 액티비티, 서비스, 브로드케스트 리시버, 콘텐츠 프로바이더를 대표적인 컴포넌트로 구성
  • 여러 프로세스로 실행가능
  • 진입점 또한 다양

 

• 짧은 시간에 여러 어플과 상호 작용
  • 인스타로 사진찍고 카카오톡으로 공유하는 도중에 전화가 걸려오면?
  • 또는 메모리 부족으로 강제 종료되면?
  • 그래도 사용자는 복귀후 작업을 재개하고 싶을 것이다. (이러한 처리를 잘 해주어야함)
  • 컴포넌트의 생명 주기는 안드로이드 시스템이 제어권을 가지기 때문에 데이터 등을 컴포넌트에 저장하는 것은 치명적일 수 있다.

 

5. 안드로이드 애플리케이션 설계 원칙

• 액티비티와 프래그먼트의 클래스 의존성을 최소화하는 것이 좋다.
  • 그 반대의 경우 예외 사항 대응이 어렵고 코드가 거대해져 가독성 저하를 불러올 수 있다.
• 관심사를 분리하자!
  • 클래스 간의 강한 의존성을 느슨하게 만들어서 모듈화를 시켜야한다.
  • 모듈이란? 다른 모듈로 부터 독립적이고 영역에 따라 다른 역할을 하는 녀석
  • 설계, 배포, 유닛 테스트 등에서 더욱 높은 자유도를 얻을 수 있다.
  • 코드가 단순화 되고, 유지 보수 측면에서 더 적은 비용이 들것이다.
  • 재사용성 증가, 독립적 개발 가능, 생산성 향상!

 

• 관심사 분리는 추상화의 일종
  • 인터페이스 사용
  • 실행에 쓰이는 더 순수한 코드

 

6. 권장하는 애플리케이션 설계

• Activity, Fragment 는 단지 ViewModel 만을 참조
• ViewModel 이 어떻게 변경되든간 Activity, Fragment 는 노관심

 

• ViewModel은 Repository라는 저장소를 참조
• UI 컴포넌트가 화면을 구성하는 데 필요한 데이터를 불러옴
• 불러온 데이터는 데이터의 변화를 감지할 수 있는 LiveData 로 관리
• 저장소
  • 내부 모델
  • 원격 네트워크 모델

 

• 내부 모델
  • 데이터베이스
  • SQLite, SQLite 기반의 Room 또는 Realm
• 원격 모델
  • Http 통신 (OkHttp, Retrofit 등 라이브러리) 를 주로 사용

• 내부 모델, 원격 모델 로부터 얻은 데이터는 ViewModel이 관리
• 변경이 감지되는 순간 UI 컴포넌트의 바인딩된 뷰에 업데이트 됨
• 사용자 경험 증진을 위해 일반적으로 서버에서 얻은 데이터는 내부 데이터베이스에 저장해 놓았다가 불러온다.

• 뷰모델은 내부 데이터베이스만 참조하게 되며
• 클라이언트 데이터베이스와 서버 데이터베이스가 요청으로 비동기적으로 동기화 되게된다.
• 이로써 전파 수신 약전계 에서도 애플리케이션이 원활 동작 가능하다
  • 전파 수신 약전계 : 오프라인 또는 느린 네트웤 상황
• 네트워크 상황이 좋아지면 다시 최신 데이터를 요청.

해당 글은 '아키텍처를 알아야 앱 개발이 보인다' 를 공부하며 요약 정리한 글 입니다.