CoroutineScope: The Parent of Your Coroutines
A CoroutineScope acts as a parent to a group of coroutines, managing their lifecycles. When the parent scope is cancelled, all its children are cancelled too. It's used with builders like launch to group related work, like in an Android ViewModel.
Why it exists
Without scopes, managing concurrent tasks is messy. If you launch 100 coroutines for a screen and the user navigates away, you'd have to track and cancel each one manually. CoroutineScope solves this by grouping coroutines so their lifecycles can be controlled as one.
The mental model
Think of a CoroutineScope as a supervisor for a team of workers (coroutines). The supervisor defines the work context, like which department they work in (the CoroutineDispatcher). If the supervisor's project is cancelled, they immediately tell all their workers to stop. The supervisor can't go home for the day (complete) until all their workers have finished their tasks.
How it works
A CoroutineScope holds a CoroutineContext, which is a map of elements defining the coroutine's behavior. The most important element is a Job, which represents the scope's own lifecycle. When you use a builder like launch on a scope, the new coroutine becomes a "child" of the scope's Job. This parent-child link is the foundation of structured concurrency. Cancelling the parent Job automatically propagates cancellation to all its children. The context also specifies other elements, like the CoroutineDispatcher (e.g., Dispatchers.IO) that determines the thread pool.
When to use it
You use a scope every time you launch a coroutine. For short-lived, nested tasks, the coroutineScope builder function is ideal as it creates a scope that ends when its block completes. For components with a defined lifecycle, like an Android Activity or ViewModel, you use a pre-defined scope tied to that lifecycle, such as lifecycleScope or viewModelScope.
When not to use it
Avoid creating your own scope with the CoroutineScope() constructor unless you are managing a custom object's lifecycle and are certain you can call cancel() when it's destroyed. Forgetting to cancel a custom scope is a common source of memory and resource leaks. Using GlobalScope is also heavily discouraged because its lifetime is tied to the application, making it very easy to leak work.
One canonical example
An Android ViewModel fetches user data from a network inside its viewModelScope. If the user rotates the screen or navigates away, the ViewModel is destroyed. The Android framework automatically calls cancel() on the viewModelScope, which in turn cancels the in-flight network request. This prevents the app from doing useless work and avoids crashes from trying to update a UI that no longer exists.
Interview question
What is the primary effect of cancelling a CoroutineScope?
- a.The CoroutineDispatcher used by the scope is permanently shut down.
- b.All coroutines that were launched within that scope are automatically cancelled.Correct
- c.New coroutines cannot be launched within that scope, but existing ones continue.
- d.Only coroutines that have not yet started execution are cancelled.
Why? this is the answer
The core function of a CoroutineScope is to manage the lifecycle of its child coroutines; thus, cancelling the scope automatically cancels all coroutines launched within it. Option C is incorrect because existing coroutines are also cancelled, not continued, and new launches would fail rather than just being prevented.
Just read this? Test yourself on what you have been reading.
Read the original → kotlinlang.org
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on kotlin — each one lists the topics its interview covers.
See open roles