Mark Murphy

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.

Here, we use withContext() to switch to our own CoroutineContext.

Now, even if the caller of these repository functions (say, a ViewModel) cancels the coroutine that is executing refresh() or clear(), the nested coroutine that is doing the work (DAO calls of a Room database in this case) will continue to completion.