Mark Murphy

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

The collect() call will throw the exception raised by the Flow, and you can use an ordinary try/catch structure to handle it.

Sometimes, though, we want to retry the work being done by the Flow in case of an exception. For example, with network I/O, some exceptions represent random failures, such as the user of a mobile device switching from WiFi to mobile data mid-way through a download.

retry(N), for a given value of N, will just blindly retry the Flow that number of times. If it continues to fail after the N tries, then the exception proceeds normally

You can optionally pass a lambda expression to retry(). This receives the exception as a parameter. Now the exception will continue to the FlowCollector if either:

We have exceeded the maximum number of retries, or
The lambda expression returns false