# Kotlin 1.3 & Android: Activities, Fragments and their CoroutineScope implementations

**URL:** https://discuss.kotlinlang.org/t/kotlin-1-3-android-activities-fragments-and-their-coroutinescope-implementations/9901
**Category:** Android
**Created:** [October 18, 2018, 3:18pm UTC](https://discuss.kotlinlang.org/t/kotlin-1-3-android-activities-fragments-and-their-coroutinescope-implementations/9901 "2018-10-18T15:18:07Z")
**Posts on this page:** 1
**Page:** 1

<div class="post-metadata">

### Author: ![mattia23](https://avatars.discourse-cdn.com/v4/letter/m/76d3ee/32.png) [@mattia23](https://discuss.kotlinlang.org/u/mattia23)
#### Post date: [October 18, 2018, 3:18pm UTC](https://discuss.kotlinlang.org/t/kotlin-1-3-android-activities-fragments-and-their-coroutinescope-implementations/9901/1 "2018-10-18T15:18:07Z")

</div>

I have just migrated an Android project to use the new structure for coroutines, by implementing CoroutineScope in my Activities and Fragments to properly bind coroutines to their lifecycle. I followed [this example](https://github.com/Kotlin/kotlinx.coroutines/blob/master/ui/coroutines-guide-ui.md#structured-concurrency-lifecycle-and-coroutine-parent-child-hierarchy).

A couple doubts came up in my mind:

1. Is `CoroutineScope.coroutineContext` getter called at every coroutine creation? Isn’t computing the returned `CombinedContext` an expensive operation? I wondered if using an assignement instead of a getter could be better in certain cases: I found that using the same initial `Job` again after it’s been canceled doesn’t work, so it makes sense to use the getter and recreate the `Job` when a new lifecycle starts, but wouldn’t it be less expensive to assign it once when we know that it won’t be used again after a cancellation?

2. How would you deal with the marvellous Fragment’s double lifecycle? Would it be ok to instantiate two `CoroutineScope`s and two `Job`s, one for the view lifecycle and one for the instance lifecycle?

Thanks for sharing thoughts and insight!