오늘도 더 나은 코드를 작성하였습니까?

Android app 아키텍처 원칙 본문

Android Jetpack Architecture/Introduction and Overview

Android app 아키텍처 원칙

hik14 2020. 8. 5. 03:23

관심사의 분리

초보 개발자는 앱을 만들다보면 UI 기반의 클래스(Activity 또는 Fragment)에 많은 코드를 작성한다.

UI 기반의 클래스는 UI 및 운영체제와 상호작용을 처리하는 로직만 포함해야 합니다. 이러한 클래스를 최대한 가볍게 유지하여 많은 수명 주기 관련 문제를 피할 수 있다.

 

Activity  Fragment 구현은 소유의 대상이 아니며 Android OS와 앱 사이의 계약을 나타내도록 이어주는 클래스일 뿐입니다. OS는 사용자 상호작용을 기반으로 또는 메모리 부족과 같은 시스템 조건으로 인해 언제든지 클래스를 제거할 수 있습니다. 만족스러운 사용자 환경과 더욱더 수월한 앱 관리 환경을 제공하려면 이러한 클래스에 대한 의존성을 최소화하는 것이 좋습니다

 

SOLID 원칙과 많은 부분이 부합되며 결국 관심사의 분리는 클래스간의 의존성을 줄이고 단일 책임을 지게 하는것이다.

관심사의 분리로 독립적 모듈화가 되면 재사용성 및 유지보수가 쉽다.

 

모델에서 UI 만들기

또 하나의 중요한 원칙은 모델에서 UI의 데이터 만들어야 한다는 것입니다. 가급적 지속적인 모델을 권장합니다. 모델은 앱의 데이터 처리를 담당하는 구성요소로, 앱의 View객체 및 앱 구성요소와 독립되어 있으므로 앱의 수명 주기 및 관련 문제의 영향을 받지 않습니다.

 

지속 모델이 이상적인 이유는 다음과 같습니다.

  • Android OS에서 리소스를 확보하기 위해 앱을 제거해도 사용자 데이터가 삭제되지 않습니다.
  • 네트워크 연결이 취약하거나 연결되어 있지 않아도 앱이 계속 작동합니다.

데이터 관리 책임이 잘 정의된 모델 클래스를 기반으로 앱을 만들면 쉽게 테스트하고 일관성을 유지할 수 있습니다.