Can anyone explain to me the benefit of a

CoroutineScope

being provided in AndroidX LifeCycle as an extension

viewModelScope

versus just having viewmodel implement

CorutineScope

?

@kevin.cianfarini Latest versions of it should use

SupervisorJob

under the hood. You can see all the latest versions on maven.google.com

I've actually stumbled upon a good way to do it which is to take as a param a CoroutineScope and implement that interface by delegatation. Should help with testing too

Don't forget to call

cancel()

from

onCleared()

abstract class CoroutineViewModel(private val scope: CoroutineScope) : ViewModel(), CoroutineScope by scope {

    override fun onCleared() {
        super.onCleared()
        this.cancel(CancellationException("ViewModel called onCleared"))
    }
}

🙂

The benefit is composition over inheritance. If they change their mind about coroutines, the ViewModel will remain untouched. Also, coroutines is just another external library and it's a tall ask to depend on it.

Also, you can make your

onCleared()

override final, or annotate it with

@CallSuper

if you still need to override it in subclasses.