skip to content

Compare flowOn, collecting inside withContext, and launchIn for controlling where flow code runs. When is each correct?

level: seniorimportance: should knowfreq 40%

answer

  1. flowOn = producer side only
  2. Collect-in-withContext/scope = collector side
  3. launchIn = lifecycle + non-blocking collection
  4. IO producer + Main collector = flowOn(IO) in a Main scope
  5. launchIn doesn't move the upstream dispatcher

basics

~10 s

flowOn sets the context for the producer side. Collecting inside withContext sets the context for the collector and everything downstream. launchIn starts collection in a scope. They solve different problems and are often combined.

solid answer

~40 s

flowOn(dispatcher) controls the UPSTREAM context (builder + operators above it) and never the collector. To control where the COLLECTOR (and all downstream operators) runs, you collect inside withContext(dispatcher) { flow.collect { } } or, in practice, collect from a coroutine launched on the right dispatcher. launchIn(scope) is sugar: flow.onEach { ... }.launchIn(scope) starts collection in that CoroutineScope without blocking, using the scope's context as the collector context. So: producer on IO + collector on Main is flow{...}.flowOn(Dispatchers.IO) collected from a Main-dispatched scope. Don't try to move the collector with flowOn (impossible) or move the producer with withContext around emit (illegal). launchIn is about lifecycle/scope, flowOn about the producer's dispatcher, withContext/scope about the collector's dispatcher.

code

kotlin · 13 lines
kotlin
import kotlinx.coroutines.*
import kotlinx.coroutines.flow.*

fun stream() = flow { emit("data") }

fun wire(scope: CoroutineScope) {
    stream()
        .flowOn(Dispatchers.IO)        // producer dispatcher
        .onEach { render(it) }          // downstream, collector context
        .launchIn(scope)               // collector context = scope's; lifecycle bound
}

fun render(s: String) = println(s)

go deeper

for a junior

Can name flowOn and collect, even if fuzzy on which side each controls.

for a middle

Correctly maps flowOn to producer and collection site to collector context.

for a senior

Cleanly separates flowOn (producer), collecting scope (collector), and launchIn (lifecycle) and combines them.

for a principal

Designs layering conventions (repo emits + flowOn, VM collects on Main) and reasons about cancellation/lifecycle implications.

## Three different knobs | Tool | Controls | Mechanism | |------|----------|-----------| | `flowOn(ctx)` | **Upstream** context (producer + ops above) | inserts a context boundary/channel | | collect inside `withContext(ctx)` / a dispatched scope | **Collector + downstream** context | the terminal runs where you call it | | `launchIn(scope)` | **When/where collection starts** (lifecycle) | launches `collect` in `scope` | ### flowOn — producer side ```kotlin val f = flow { emit(loadFromDisk()) } .flowOn(Dispatchers.IO) // producer on IO ``` `flowOn` can ONLY relocate upstream. It cannot move the collector. ### withContext / dispatched scope — collector side The terminal `collect` (and any operator below the last `flowOn`) runs wherever you collect: ```kotlin withContext(Dispatchers.Main) { f.collect { updateUi(it) } // collector + downstream on Main } ``` This is how context preservation works — the collection site fixes the downstream context. ### launchIn — lifecycle sugar `launchIn(scope)` is shorthand for `scope.launch { collect() }`, usually paired with `onEach`: ```kotlin f.onEach { updateUi(it) } .launchIn(viewModelScope) // collector context = viewModelScope's ``` It does NOT change which dispatcher collects beyond the scope's context; it controls **when collection starts and its parent Job** (cancellation tied to `scope`). ## Putting it together (classic Android pattern) ```kotlin repository.streamData() // suspending IO work inside .flowOn(Dispatchers.IO) // producer on IO .onEach { state -> render(state) } .launchIn(viewModelScope) // collector on Main (scope's dispatcher), tied to VM lifecycle ``` Producer = IO via `flowOn`; collector = Main via the scope; lifecycle = `viewModelScope` via `launchIn`. ## Anti-patterns - `flowOn` to move the **collector** — impossible; it only moves upstream. - `withContext` around `emit` to move the **producer** — illegal, throws. - Using `launchIn` expecting it to change the upstream dispatcher — it doesn't; add `flowOn` for that. ## Key APIs/keywords - `flowOn`, `withContext`, `launchIn`, `onEach` - `CoroutineScope`, `viewModelScope`, `Dispatchers.Main/IO` - `collect` (terminal) vs `launchIn` (non-blocking terminal)

  • Can launchIn change which dispatcher the upstream runs on?
    No. launchIn only sets the scope/lifecycle and the collector's context. To set the upstream dispatcher you still need flowOn.
  • How do you run the producer on IO but update UI on Main in one chain?
    Apply flowOn(Dispatchers.IO) to the upstream and collect (or launchIn) from a Main-dispatched scope so downstream/collector stays on Main.

flowOn picks the kitchen, the collecting scope picks the dining room, and launchIn just opens the restaurant for service.

saying these in an interview costs you the question

  • Using flowOn to try to relocate the collector
  • Thinking launchIn replaces flowOn for choosing the producer thread
  • Putting flowOn(Dispatchers.Main) at the end and expecting UI safety for collect
  • Confusing the scope's Job (lifecycle) with the upstream dispatcher

context

resolving links…