ViewModel에서 더이상 EventFlow를 사용하지 마세요

핵심 내용

• 안드로이드 ViewModel의 1회성 이벤트 전파 방식으로 쓰던 EventFlow를 Channel로 대체한 사례
• 구독자가 없을 때도 이벤트를 보관하고, 한 번 처리된 이벤트는 다시 전달되지 않는 요구사항 정리
• 발행부는 send에서 emit으로, 수집부는 receiveAsFlow()로 맞추는 단순한 변경 포인트
• Channel.BUFFERED와 receiveAsFlow()를 사용해야 하는 이유와 주의점 설명

선택 이유

• EventFlow와 Channel이 요구사항을 충족하는 방식 비교
• Channel이 별도 구현 없이도 이벤트 보관과 단발성 소비를 처리하는 점

주의할 점

• Channel 기본값인 RENDEZVOUS에서는 수신자가 없으면 send가 중단될 수 있음
• trySend는 수신자가 없을 때 이벤트 유실 가능성 존재
• consumeAsFlow()는 UI의 반복 collect와 맞지 않음

적용해볼 점

• ViewModel의 이벤트 전파를 SharedFlow 기반 커스텀 구현보다 Channel로 단순화
• 1개 ViewModel을 1개 UI가 observe하는 구조라면 Channel의 단일 구독자 제약은 큰 문제 없음