Mark Murphy

flowOf() might seem pointless. After all, if we already have the objects, why do we need to bother with a Flow? However, there are a few cases where that is indeed what we want, such as:

Testing, where we need to provide a Flow and we already have our test data to provide
Error conditions, where we have our error object already, but the API that we are implementing requires a Flow (perhaps of a sealed class representing loading/content/error states)

emptyFlow() is basically flowOf() with no parameters. It returns a flow that is already closed, so a collect() call will just return immediately.

A slightly safer version of single() is singleOrNull(). This:

Returns null for an empty Flow (one that closes without emitting anything)
Returns the emitted object for a single-object Flow
Throws an exception if the Flow does not close after emitting its first object

first() is reminiscent of single() and singleOrNull(), in that it returns one object from the Flow. However, it then stops observing the Flow, so it is safe to use with a Flow that might return more than one value.

Flows do not wind up on some other dispatcher by magic. Instead, they use the same dispatcher mechanism as we use for the rest of coroutines.

Another option is to use flowOn() to customize the Flow

Now, the lambda expression will run on Dispatchers.Default, but our collection of the results will be performed on Dispatchers.Main (courtesy of the launch() dispatcher).

onStart(), allows you to inject new values before the “real” content emitted by the Flow:

Anything you emit() from onStart() will be emitted by the Flow first.

The default behavior of Flow mirrors what happens with a suspend function that throws an exception: you can just catch it