조용한 개발 노트

이전 글에서는 Cold Flow와 Hot Flow의 차이, 그리고 StateFlow, SharedFlow의 개념을 살펴봤습니다.이제 자연스럽게 이런 질문이 남습니다. “그래서 실무에서는 이걸 어떻게 써야 하지?” 이 글에서는 Kotlin 공식 문서에서 소개한 개념을 바탕으로, 실무에서 가장 널리 쓰이는 상태(State)와 이벤트(Event)를 분리하는 패턴을 하나의 예제로 정리합니다.1. 실무에서 가장 흔한 문제UI나 API 응답을 Flow로 표현하다 보면 다음 두 종류의 데이터가 섞이기 쉽습니다.현재 화면이 어떤 상태인지한 번만 처리되어야 하는 이벤트이 둘을 같은 Flow로 처리하면 다음과 같은 문제가 발생합니다.화면 회전이나 재구독 시 이벤트가 다시 발생상태 변경과 이벤트 처리 로직이 뒤섞임colle..

이전 글에서는 Flow 연산자와 예외 처리를 통해 값과 예외가 어떻게 흐르는지를 살펴봤습니다.지금까지 다룬 Flow에는 한 가지 중요한 공통점이 있었습니다.collect가 호출될 때마다 Flow가 새로 실행된다이런 Flow를 Kotlin 공식 문서에서는 Cold Flow라고 부릅니다.이번 글에서는 Cold Flow와 다른 개념인 Hot Flow를 소개하고, 그 대표 구현인 StateFlow와 SharedFlow를 공식 문서 기준으로 정리합니다.1. Cold Flow 다시 짚어보기Cold Flow의 가장 큰 특징은 collect 시점에 실행이 시작된다는 점입니다.val flow = flow { println("start") emit(1)}flow.collect { println(it) }flow..

Flow를 공부하다 보면 자연스럽게 이런 질문이 생깁니다.“Flow에서 값은 무조건 emit으로만 생기는 걸까?”결론부터 말하면, 이 질문은 절반은 맞고, 절반은 틀립니다. 이 글에서는 Kotlin 공식 문서의 Flow 개념을 기준으로, 이 오해를 정확히 정리해봅니다.1. Flow에서 말하는 “값”이란 무엇인가?Flow에서 말하는 값은 collect까지 흘러가는 데이터를 의미합니다.flow { emit(1) emit(2)}.collect { value -> println(value)}여기서 collect가 받는 value는 Flow 관점에서의 “값”입니다.그리고 이 값은 방출(emit)된 값입니다.2. 그렇다면 값은 항상 emit으로만 만들어질까?여기서 중요한 구분이 하나 필요합니다.값을..