https://kotlinlang.org logo
Title
u

ursus

10/24/2020, 7:25 PM
3) Its me with rxjava
startWith
and flow
onStart
again
CoroutineScope(SupervisorJob() + <http://Dispatchers.IO|Dispatchers.IO>).launch {
	flowOf(1)
		.onStart { emit(0) }
		.collect {
			stateFlow.value = it
		}
}

-- is equivalent to:
Observable.just(1)
	.startWith(0) <---
	.subscribeOn(<http://Schedulers.io|Schedulers.io>()) <---
	.subscribe {
		behaviorRelay.accept(it)
	}

-- In rx I use:
Observable.just(1)
	.subscribeOn(<http://Schedulers.io|Schedulers.io>()) <---
	.startWith(0) <--- swapped
	.subscribe {
		behaviorRelay.accept(it)
	}
is this doable somehow in flow? (to not have the onStart emit coming from io thread)
g

gildor

10/25/2020, 3:26 AM
Isn;t in another thread it was already explained that onStart has different semantics and how to implement iperator which works on startWith?
onStart doesn’t prevent upstream flow to emit, it’s just a side effect which may emmit too
u

ursus

10/25/2020, 1:42 PM
How has it different semantics? In the previous thread where you and Jake replied, the issue basically was I used lambda.asFlow, wrongly. when correctly turning suspend fun to flow it worked as expected
g

gildor

10/25/2020, 2:25 PM
I don't think so, because onStart doesn't guarantee order of emits! So if you onStart is slower, it will return later than your lambda
So it works just because onStart is faster in your case
u

ursus

10/25/2020, 2:29 PM
Ok didnt expect it wasnt guaranteed to be first, thanks