원칙 2. 데이터 모델에서 UI 도출하기(Drive UI from data models)
안드로이드 컴포넌트와는 독립적인 데이터 모델을 선언해 앱의 데이터를 관리하고, UI 를 해당 모델로부터 도출하라는 원칙입니다. 데이터 모델은 UI 및 앱 구성 요소 라이프사이클에 연결되어 있지 않지만 OS가 메모리에서 앱의 프로세스를 제거하기로 결정하면 여전히 삭제됩니다.
데이터 모델에서 UI 도출하기 원칙을 지켰을 때의 장점
- 안드로이드 OS가 리소스를 확보하기 위해 앱을 파괴해도 사용자는 데이터를 잃지 않습니다.
- 네트워크 연결이 끊어지거나 사용할 수 없는 경우에도 앱이 계속 작동합니다.
원칙 3. 단일 소스 저장소(Single source of truth)
앱에 새로운 데이터가 필요하면, SSOT원칙을 적용해서 선언하는게 좋습니다. SSOT는 데이터의 소유자이며, SSOT만 데이터를 수정할 수 있습니다. 이런 특징을 구현하기 위해 SSOT는 불변 유형으로 데이터를 노출하고, 다른 유형이 호출할 수 있는 이벤트를 수신하거나 메서드를 노출해 데이터를 수정합니다.
ex) ViewModel 에서 구독 가능한 데이터 노출 시 private MutableSharedFlow, public SharedFlow 나눠서 필드 정의하는 컨벤션도 이 원칙과 관련이 있습니다.
단일 소스 저장소 원칙을 지켰을 경우의 장점
- 특정 유형 데이터의 모든 변경사항을 한 곳에서 관리하기 때문에 일원화되어 관리가 쉽습니다.
- 다른 유형이 임의로 조작할 수 없도록 데이터를 보호합니다.
- 데이터 변경사항을 쉽게 추적할 수 있습니다.
원칙 4. 단방향 데이터 흐름(Unidirectional Data Flow)
단방향 데이터 흐름(UDF) 패턴에서 상태는 한 방향으로만 흐릅니다. 데이터 흐름을 수정하는 이벤트는 반대 방향으로 흐릅니다.
안드로이드 앱에서 상태 또는 데이터는 일반적으로 상위 계층 유형에서 하위 계층 유형으로 흐릅니다. 이벤트는 보통 하위 계층 유형에서 트리거되어 상응하는 데이터 유형의 SSOT에 도달합니다.
ex) 애플리케이션 데이터는 보통 데이터 소스에서 UI로 흐릅니다. 버튼 누르기와 같은 사용자 이벤트는 UI에서 SSOT로 흐르며, SSOT에서는 애플리케이션 데이터가 불변 유형으로서 수정 및 변경됩니다.
단방향 데이터 흐름 원칙을 지켰을 경우의 장점
- 데이터 일관성을 강화(observable state holder 를 사용해서, 상태 업데이트를 즉각 UI에 반영 가능)
- 오류가 발생할 확률을 줄여 줌
- 관심사를 분리했기 때문에 테스트 하기 쉬움
'안드로이드 개발' 카테고리의 다른 글
안드로이드 개발자 면접 준비 : 안드로이드 아키텍쳐 기본 원칙 (1) (0) | 2023.06.21 |
---|