KotlinConf 2019: Asynchronous Data Streams with Kotlin Flow by Roman Elizarov
Why Stack Overflow recommends it
Stack Overflow users link it when explaining how Kotlin Flow works, such as why a flow is cold and runs declaratively instead of at call time, and how it fits with structured concurrency.
Recommended by 1 people across 1 different months, 2020 to 2021.
What it is
A KotlinConf 2019 talk by Roman Elizarov, who designed Kotlin coroutines, on Kotlin Flow, a declarative API for asynchronous data streams built on coroutines and structured concurrency. It covers basic design, usage patterns, implementation internals, performance, and how Flow relates to Rx and Reactive Streams.
What people said
Recommends adamhurwitz.eth · 2020-03 · Stack Overflow · on “Runtime error for suspend function when implementing launchIn”
The issue has been resolved. The problem was that the getFeed method, was implemented with the suspend syntax. suspend is not needed when returning a Flow, because Flow is run declaratively, meaning getFeed defines the code that will be run when called. The code will run when launchIn initiates it rather than being run imperatively when the method is first called by itself. This concept is defined well in this talk, KotlinConf 2019: Asynchronous Data Streams with Kotlin Flow by Roman Elizarov [this video] Before suspend fun getFeed() = flow { ... } After fun getFeed() = flow { ... }
Cites marstran · 2020-02 · Stack Overflow · on “Kotlin wrap sequential IO calls as a Sequence”
Question 1 : The API-request will still run on the IO-dispatcher, but it will block the thread it's running on. This means that no other tasks can be scheduled on that thread while waiting for the request to finish. There's not really any reason to use runBlocking in production-code at all, because: If makeRequest is already a blocking call, then runBlocking will do practically nothing. If makeRequest was a suspending call, then runBlocking would make the code less efficient. It wouldn't yield the thread back to the pool while waiting for the request to finish. Whether makeRequest is a blocking or non-blocking call depends on the client you're using. Here's a non-blocking http-client I can r
Cites Akhha8 · 2021-08 · Stack Overflow · on “Kotlin Flow: emitAll is never collected”
Well, in your test when you use toList() you are using a terminal operator which only get the first element emitted from flow(null value), try to collect the values from test, networkBoundResource(..., coroutineDispatcher).collect{ it-> // TODO - read "it", which is the emitted value. } Note: I am assuming that you are using structured concurrency with coroutines. [this video]