UI 이벤트는 UI 레이어에서 UI 또는 ViewModel로 처리해야 하는 작업입니다.
- UI 이벤트: UI 레이어에서 처리해야 하는 작업입니다.
- 사용자 이벤트: 사용자가 앱과 상호작용할 때 생성하는 이벤트입니다.
데이터 홀더는 일반적으로 특정 사용자 이벤트의 비즈니스 로직을 처리합니다.
사용자 이벤트 처리
확장 가능한 항목의 상태와 같이 UI 요소의 상태 수정과 관련된 경우 UI에서 사용자 이벤트를 직접 처리할 수 있습니다. 이벤트가 화면상 데이터의 새로고침 같은 비즈니스 로직을 실행해야 하는 경우 데이터 홀더로 처리해야 합니다.
ViewModel 이벤트 처리
ViewModel에서 발생하는 UI 작업(ViewModel 이벤트)은 항상 UI 상태 업데이트로 이어집니다.
ViewModel은 UI가 화면에 메시지를 표시하는 방식을 알 필요가 없습니다. 표시해야 하는 사용자 메시지가 있다는 사실만 알면 됩니다.
탐색 이벤트
탐색 전에 데이터 입력에 비즈니스 로직 확인이 필요하면 ViewModel은 UI에 상태를 노출해야 합니다. UI는 상태 변경에 반응하고 적절하게 이동합니다.
기타 사용 사례
UI 상태 업데이트로 UI 이벤트 사용 사례를 해결할 수 없다고 생각되면 앱의 데이터 흐름 방식을 다시 고려해야 할 수도 있습니다. 다음 원칙을 고려하세요.
- 각 클래스에서 각자의 역할만을 수행해야 합니다. UI는 탐색 호출, 클릭 이벤트, 권한 요청 가져오기와 같은 화면별 동작 로직을 담당합니다. ViewModel은 비즈니스 로직을 포함하며 계층 구조의 하위 레이어에서 얻은 결과를 UI 상태로 변환합니다.
- 이벤트가 발생하는 위치를 생각해 보세요. 이 가이드의 시작 부분에 있는 결정 트리를 따르고 각 클래스가 담당하는 역할을 처리하게 합니다. 예를 들어 이벤트가 UI에서 발생하고 그 결과 탐색 이벤트가 발생하면 이 이벤트는 UI에서 처리되어야 합니다. 일부 로직이 ViewModel에 위임될 수 있지만, 이벤트 처리는 ViewModel에 완전히 위임될 수 없습니다.
- 소비자가 여러 명이고 이벤트가 여러 번 소비될 것이 우려된다면 앱 아키텍처를 다시 고려해야 할 수도 있습니다. 동시 실행 소비자가 여럿인 경우 정확히 한 번 제공되는 계약을 보장하기가 매우 어려워지므로 복잡성과 미묘한 동작의 양이 폭발적으로 증가합니다. 이 문제가 발생하면 UI 트리의 위쪽으로 문제를 푸시해 보세요. 계층 구조의 상위로 범위가 지정된 다른 항목이 필요할 수 있습니다.
- 상태를 소비해야 하는 경우를 생각해 보세요. 어떤 상황에서는 앱이 백그라운드에 있다면 계속 소비하지 않는 것이 좋을 수 있습니다(예: Toast 표시). 이 경우 UI가 포그라운드에 있을 때 상태를 소비하는 것이 좋습니다.
'아키텍처' 카테고리의 다른 글
[앱 아키텍처] 상태 호이스팅 (1) | 2024.01.30 |
---|---|
[앱 아키텍처] UI 레이어의 상태 홀더 (1) | 2024.01.30 |
[앱 아카텍처] UI 레이어 (0) | 2024.01.30 |
[앱 아키텍처] 권장 앱 아키텍처 (0) | 2024.01.30 |
[앱 아키텍처] Google의 일반적인 아키텍처 원칙 (0) | 2024.01.30 |