Kotlin CoroutineScope initialization depending upon CoroutineContext with custom getter

Question

The google codelab Android Room with a View - Kotlin has the following snippet:

class WordViewModel(application: Application) : AndroidViewModel(application) {

    // ...

    private val coroutineContext: CoroutineContext
       get() = parentJob + Dispatchers.Main

    private val scope = CoroutineScope(coroutineContext)

    // ...

}

And from what I understand from this answer, the custom getter is evaluated everytime, whereas the assignment is evaluated at the time of constructing only. So in effect, scope would take a value that wouldn't change later, so what use is the custom getter for coroutineContext?

Answer 1

The definition of coroutineContext as a computed property (or custom getter) makes more sense when you are defining a CoroutineScope in a component with lifecycle (i.e. Android Activity). The example in the Javadoc is self-explanatory:

class MyActivity : AppCompatActivity(), CoroutineScope {
    lateinit var job: Job
    override val coroutineContext: CoroutineContext
        get() = Dispatchers.Main + job

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        job = Job()
    }

    override fun onDestroy() {
        super.onDestroy()
        job.cancel() // Cancel job on activity destroy. After destroy all children jobs will be cancelled automatically
    }
}

In this case, you are creating the Job in a lifecycle method, that's why you need the computed property to return the coroutineContext with the Job instance created in onCreate.

Answer 2

I think in this example we can get rid of

private val coroutineContext: CoroutineContext
   get() = parentJob + Dispatchers.Main

and just write

private val scope = CoroutineScope(parentJob + Dispatchers.Main)

So the result code will look like:

class WordViewModel(application: Application) : AndroidViewModel(application) {
    private var parentJob = Job()
    private val scope = CoroutineScope(parentJob + Dispatchers.Main)
    // ...
}

I guess it is a matter of style to write getter in this case. Nothing will change if we remove it.