Dennis Schröder
10/01/2019, 9:52 PMsuspend fun someFunctionCreatesAFlow(context: Dispatchers.Default): Flow<String> = withContext(context) {
flow {
emit(somethingAsAString)
}
}
I guess it is because Flows kinda manage their own context with flow::flowOn()
. Can anybody confirm this?suspend fun someFunctionCreatesAFlow(context: Dispatchers.Default): Flow<String> = coroutineScope {
flow {
emit(somethingAsAString)
} .flowOn(context)
}
Dominaezzz
10/01/2019, 9:59 PMsuspend fun someFunctionCreatesAFlow(context: Dispatchers.Default): Flow<String> = flow {
emit(somethingAsAString)
} .flowOn(context)
Dennis Schröder
10/01/2019, 9:59 PMsuspend CoroutineScope.() -> String
. Therefore I need a scopeoctylFractal
10/01/2019, 9:59 PMflow
isn't a suspend function itself, only terminal operations, so it doesn't pass any of the context to the flow. technically that function doesn't need to be suspend at allDennis Schröder
10/01/2019, 9:59 PMoctylFractal
10/01/2019, 10:00 PMflow { }
flow {
coroutineScope {
...
}
}
louiscad
10/01/2019, 11:08 PMflowOn
.streetsofboston
10/01/2019, 11:40 PMPablichjenkov
10/02/2019, 9:00 PMFlow.collect()
from a scope that has a Dispatcher.UI type.
Will the flow chain process in this UI scope by default?
Am I forced to use flowOn(IOContext)
to make it execute off the UI thread?streetsofboston
10/02/2019, 9:04 PMPablichjenkov
10/02/2019, 9:08 PMlouiscad
10/02/2019, 9:16 PMoctylFractal
10/02/2019, 9:18 PMflowOn
, then everything setup before that call runs in the context passed there (calls after flowOn
still use the same dispatcher as the terminal op caller)Pablichjenkov
10/02/2019, 9:37 PM// case 1
flow {
suspendingBlockingFunc()
}
//and case 2
flow {
nonSuspendingBlockingFunc() // Blocks either by IO or heavy CPU
}
If not using flowOn
operator and calling collect()
from Dispatcher.UI.
Case 1 flow will execute on UI killing it
Case 2 flow will execute on where? -> Default?octylFractal
10/02/2019, 9:38 PMcollect()
Pablichjenkov
10/02/2019, 9:39 PM