Scribd
Upload
50 views8 pages

The Difference Between Kotlin Flows

The document summarizes different types of Kotlin Flows: Flow is the basic abstraction that can be either cold or hot. Cold flows like those built with flow {} only run when collected. SharedFlow is hot and can receive elements regardless of subscribers. StateFlow inherits SharedFlow and always has a value present, useful for observing state updates. ChannelFlow uses channels and allows concurrent emission. CallbackFlow converts callback APIs to flows.

Uploaded by

morsi5038
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
50 views8 pages

The Difference Between Kotlin Flows

The document summarizes different types of Kotlin Flows: Flow is the basic abstraction that can be either cold or hot. Cold flows like those built with flow {} only run when collected. SharedFlow is hot and can receive elements regardless of subscribers. StateFlow inherits SharedFlow and always has a value present, useful for observing state updates. ChannelFlow uses channels and allows concurrent emission. CallbackFlow converts callback APIs to flows.

Uploaded by

morsi5038
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 8

January 2023

The difference
between Flows

BY VADYM YAROSHCHUK
WHAT ARE KOTLIN FLOWS?
In simple terms, Kotlin Flows are a way to handle sequences of values
asynchronously in Kotlin. It allows you to represent a stream of data
that can be processed sequentially. Unlike Channels that’s hot by
definition, Flows divide into two types: cold and hot.
TYPES OF FLOW
Flow SharedFlow StateFlow
The basic abstraction of any A hot flow that can receive The type of SharedFlow
flow. Without implementation elements regardless of number where we always have a
details, you can only collect of consumers (there can even value present. We usually use
elements that can be cold or be no one). Has replayCache this type of flow in our mobile
hot (look for other types of to provide recent elements applications to observe state
flow for details). If it’s builtin (published before updates from UI-side.
with flow {} – it’s cold. subscribing) for new
consumers.

ChannelFlow
The cold type of Kotlin Flows
that uses Channel APIs in its
builders. The peculiarity of this
Flow subtype is that there is
no restriction on the context
of where we emit values into
our Flow (we can emit them
concurrently).
FLOW
When we talk about regular
flow, it’s usually done by a
several builders for different
use-cases. The most common one
is the flow {} builder (usually we
use it when we want to make
some kind of computations that
should be done lazily).

All this builders are producing


‘cold’ flows that are executed
once they’re requested in the
‘collect’ block.
SHAREDFLOW
As was mentioned earlier, this
type of flow is hot. It means
that you can emit without any
subscriber. It’s also adapted
to situations when there’s
multiple possible subscribers
that consumes flow with the
delay by replayCache.
STATEFLOW
This type of flow actually inherits the
SharedFlow (and it’s also hot
obviously) with
some sort of additional functions.
Alternative to StateFlow is the
LiveData on Android.

It has a compareAndSet function


(that is actually used in the update
function) to avoid inconsistency within
concurrency by checking the current
value of stateflow and the given one.

*update function will be called multiple


times if compareAndSet returns false
CHANNELFLOW
ChannelFlow facilitates concurrent
emission from different coroutines with
structured concurrency. It's ideal for
scenarios requiring parallel processing.
The first example demonstrates emission
in specific coroutine contexts.

CallbackFlow is beneficial for


integrating external updates through
traditional callbacks. It seamlessly
converts callback-based updates into a
flow of values, bridging asynchronous
APIs with Kotlin coroutines
expressiveness. The awaitClose block
ensures proper cleanup when the flow is
no longer needed, unregistering
callbacks as necessary.
THANKS FOR READING!

You might also like