The is a kind of scope in the world of coroutines that challenges a lot of developers and prompts many to say that it is not useful, and it was probably a bad idea to introduce it in the standard library anyway since it’s not highly recommended. The reason for this seems to stem from the fact that we cannot tie the created coroutines with any specific lifecycle. This can be problematic in any kind of programming, but especially where we mostly tie coroutines to the lifecycle of fragments or activities. In the video, to which you can find the link below, I am casually talking about that while walking in Gouda by the Groenhovenpark. GlobalScope Kotlin kotlix GlobalScope android programming To exemplify how the operates and why it can be a problem to use it I created an example that you can explore by issuing these commands: GlobalScope git clone https://github.com/jesperancinha/jeorg-kotlin-test-drives.git
cd jeorg-kotlin-coroutines/coroutines-crums-group-1
make b The example class is which is an executable class and the code is this one: GlobalScopeCoroutine class GlobalScopeCoroutine {
    companion object {
        @OptIn(DelicateCoroutinesApi::class)
        @JvmStatic
        fun main(args: Array<String> = emptyArray()) {
            val job = GlobalScope.launch {
                delay(1.seconds.toJavaDuration())
            }
            println("Global >> Is the Global job cancelled? ${job.isCancelled}")
            println("Global >> Is the Global job active? ${job.isActive}")
            println("Global >> Is the Global job completed? ${job.isCompleted}")
            job.cancel()
            println("Global >> Is the Global job cancelled after cancel? ${job.isCancelled}")
            runBlocking {
                val jobInScope = launch {
                    delay(1.seconds.toJavaDuration())

                }
                jobInScope.cancel()
                println("First Job >> Is this job cancelled? ${jobInScope.isCancelled}")
            }
            val lastJob = runBlocking {
                val jobInScope = launch {
                    delay(1.seconds.toJavaDuration())

                }
                println("Second Job >> Is this job cancelled? ${jobInScope.isCancelled}")
                println("Second Job >> Is this job active? ${jobInScope.isActive}")
                println("Second Job >> Is this job completed? ${jobInScope.isCompleted}")
                jobInScope
            }
            println("Second Job After Life-Cycle >> Is this job cancelled? ${lastJob.isCancelled}")
            println("Second Job After Life-Cycle >> Is this job active? ${lastJob.isActive}")
            println("Second Job After Life-Cycle >> Is this job completed? ${lastJob.isCompleted}")
        }
    }
} In the first part of the code we can launch a coroutine wih the . Immediately we should observe that we can launch this coroutine without the need to already be in a Global scope. In this case, we only have access to our in our localstack. This is the only place where we have access to a provision to be able to cancel that coroutine. We can also observe that nothing else is bound to that coroutine and that is is now running without any attachment to any lifecycle. After this call in a real program, this coroutine would be running in the background until it would stop or it would remain running in case of a problem without us being able to stop it anywhere in the application. We can of course still cancel it in this localstack. GlobalScope job In the following coroutine builder, we launch a coroutine in scope and we can observe that we can also cancel it in the same way as we did before with the . runBlocking GlobalScope It is in the last call that we can observe something different. In this case, we do not cancel the coroutine. Instead, we just let it run until the lifecycle ends. We can finally observe that this coroutine is not completed in the blocking scope but when it comes out, it does get completed: runBlocking Global >> Is the Global job cancelled? false
Global >> Is the Global job active? true
Global >> Is the Global job completed? false
Global >> Is the Global job cancelled after cancel? true
First Job >> Is this job cancelled? true
Second Job >> Is this job cancelled? false
Second Job >> Is this job active? true
Second Job >> Is this job completed? false
Second Job After Life-Cycle >> Is this job cancelled? false
Second Job After Life-Cycle >> Is this job active? false
Second Job After Life-Cycle >> Is this job completed? true It is always quite difficult to explain this phenomenon, but the whole idea is that, if we have our framework manage the lifecycle of the coroutines we use then that is much better than using a detached scope like the . GlobalScope In the literature, we find that may still be used for some exceptional purposes like logging and monitoring. However for that purpose, there are already several frameworks that allow us to do so and this is the reason why for the most part, is always 100% not advised to use. GlobalScope GlobalScope https://youtube.com/shorts/wqL_1imGhaY?feature=shared&embedable=true Also published here.

The writer is smart, but don't just like, take their word for it. #DoYourOwnResearch before making any investment decisions or decisions regarding your health or security. (Do not regard any of this content as professional investment advice, or health advice)

Too Long; Didn't Read

In your car, at home, or at work — Bosch technology shapes many areas of life.

GlobalScope in Kotlin Coroutines: Is It Really Worth the Risk?

Too Long; Didn't Read

João Esperancinha

STORY’S CREDIBILITY

DYOR

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

GlobalScope in Kotlin Coroutines: Is It Really Worth the Risk?

Too Long; Didn't Read

João Esperancinha

STORY’S CREDIBILITY

DYOR

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

RELATED STORIES