Mark Murphy

Retrofit will know to code-generate an implementation of NWSInterface that uses withContext() to have the actual network I/O be conducted on a Retrofit-supplied dispatcher.

you add the suspend keyword to a @Dao function, Room will know to code-generate an implementation that performs the database I/O in a CoroutineContext that uses a Room-supplied dispatcher.

you might want to have model objects that differ from Retrofit responses or Room entities, and the repository would convert between those as needed.

The ViewModel might be tasked with converting the model objects or other data into forms appropriate for rendering (e.g., converting an Instant into a formatted String). The ViewModel also often needs to deal with things like tracking whether the coroutine is still running (so we can show a loading state) or whether it threw an exception (so we can show an error state). And, we want the ViewModel to be able to handle the Android activity/fragment lifecycle, so we can get the results of our coroutines even if the user rotated the screen (or underwent another type of configuration change) while that work was proceeding.

For read operations, viewModelScope usually works fine. If the user navigates away from our activity or fragment, most likely we no longer need the data that we are trying to load. Canceling the CoroutineScope may save us some CPU time, network bandwidth, etc.

However, typically a write operation is one that we want to have succeed, even if the user navigates away. Just because they were quick to tap the BACK button does not mean that they want to lose the data they just entered and asked to save to the database or server.

There are a few approaches for addressing this problem.

One approach is to mark the critical work as NonCancellble. This will tell the coroutines system to not cancel this coroutine, even if its scope is canceled.

So, for example, a repository could wrap its Room DAO write calls in a NonCancellable coroutine:

The downside is that the coroutine cannot be canceled at all, and the code in that coroutine might assume that it can be cancelled normally.

Another approach is to switch to a different CoroutineScope, one that will not be canceled by the user navigating away from our UI. For example, you could use GlobalScope… but we do not have a lot of control over the behavior of GlobalScope.

But, we can create our own CoroutineScope easily enough

The SupervisorJob will ensure that any exceptions or intentional cancellations from one coroutine will not cause other coroutines in that scope to be canceled.