Course: Android App Development
Topic: Using Dispatchers and Coroutine Scopes
Course Link: Android App Development Course
Demo Link: Register for a Course Demo
Official Website: JustAcademy
Kotlin coroutines are widely used in Android development to perform asynchronous operations without blocking the user interface. Applications use coroutines for network requests, database operations, file handling, image processing, and other background tasks.
Two important concepts in coroutine programming are Dispatchers and Coroutine Scopes. A dispatcher determines the execution context used by a coroutine, while a scope manages the coroutine's lifecycle and relationships with other coroutines.
Using the correct dispatcher helps keep the main thread responsive. Using the correct scope ensures that background work is cancelled when it is no longer needed.
A coroutine dispatcher determines which thread or thread pool is used to execute coroutine code. It can schedule work on the Android main thread or on background threads, depending on the selected dispatcher.
Coroutines do not necessarily remain on one thread throughout their execution. They can suspend and resume later, potentially on a different thread, according to their coroutine context and dispatcher.
Kotlin provides several standard dispatchers for different kinds of work.
| Dispatcher | Purpose | Typical Examples |
|---|---|---|
| Dispatchers.Main | Runs coroutine code on the main UI thread. | Updating views and UI state. |
| Dispatchers.IO | Designed for blocking input/output operations. | File operations and blocking I/O APIs. |
| Dispatchers.Default | Designed for CPU-intensive computation. | Sorting, complex calculations, and data processing. |
| Dispatchers.Unconfined | Starts in the caller context until the first suspension, then follows the resumption behavior of the suspending operation. | Specialized advanced scenarios. |
Important: Dispatchers.IO is designed for blocking I/O work. Many modern libraries, including Retrofit suspend APIs and Room suspend queries, already provide appropriate asynchronous behavior. Follow the library's documentation instead of automatically switching every call to Dispatchers.IO.
Dispatchers.Main executes coroutine code on Android's main thread. This dispatcher is appropriate for short UI-related tasks, such as updating a view or publishing UI state.
import kotlinx.coroutines.Dispatchers
import kotlinx.coroutines.launch
import kotlinx.coroutines.withContext
import androidx.lifecycle.ViewModel
import androidx.lifecycle.viewModelScope
class MainViewModel : ViewModel() {
fun updateMessage() {
viewModelScope.launch(Dispatchers.Main) {
val message = withContext(Dispatchers.Default) {
"Processing completed"
}
// This code runs on the main dispatcher.
println(message)
}
}
}The coroutine begins on the main dispatcher. The calculation block switches to Dispatchers.Default, then execution returns to the original dispatcher when the block completes.
Avoid blocking operations and heavy calculations on Dispatchers.Main because they can freeze the interface.
Dispatchers.IO is designed for blocking input/output operations. It provides a shared pool of threads that can be used for tasks that spend time waiting for external resources.
import kotlinx.coroutines.Dispatchers
import kotlinx.coroutines.withContext
import java.io.File
suspend fun readFileContents(file: File): String {
return withContext(Dispatchers.IO) {
file.readText()
}
}The file is read inside the IO dispatcher, so the blocking file operation does not run on the caller's main thread.
import androidx.lifecycle.ViewModel
import androidx.lifecycle.viewModelScope
import kotlinx.coroutines.launch
import java.io.File
class FileViewModel : ViewModel() {
fun loadFile(file: File) {
viewModelScope.launch {
try {
val contents = readFileContents(file)
// Publish contents to the UI state.
} catch (e: Exception) {
// Publish an error state.
}
}
}
}In production, preserve coroutine cancellation by rethrowing CancellationException rather than treating it as an ordinary error.
Dispatchers.Default is designed for CPU-intensive tasks. It uses a shared pool of background threads to execute computations without occupying the main thread.
import kotlinx.coroutines.Dispatchers
import kotlinx.coroutines.withContext
suspend fun calculateTotal(numbers: List<Int>): Long {
return withContext(Dispatchers.Default) {
numbers.sumOf { it.toLong() }
}
}The calculation executes on Dispatchers.Default. The function returns the computed total when the coroutine resumes and the operation finishes.
Do not use it automatically for every task. Simple calculations may not need a dispatcher switch. For blocking file or I/O operations, Dispatchers.IO is generally more suitable.
Dispatchers.Unconfined is a specialized dispatcher. It starts coroutine execution in the calling thread until the first suspension point. After suspension, the coroutine resumes according to the behavior of the suspending operation.
import kotlinx.coroutines.Dispatchers
import kotlinx.coroutines.delay
import kotlinx.coroutines.launch
import kotlinx.coroutines.runBlocking
fun main() = runBlocking {
launch(Dispatchers.Unconfined) {
println("Before suspension")
delay(100)
println("After suspension")
}
}The exact thread used after suspension depends on the suspending operation. Therefore, Dispatchers.Unconfined should not be treated as a general-purpose background dispatcher.
It is rarely needed in typical Android application code. Prefer Main, IO, or Default when their execution characteristics match the task.
A CoroutineScope provides a context in which coroutines can be launched and managed. It helps define the lifecycle of related work and enables structured concurrency.
A scope does not itself select a thread. Its coroutine context can contain a dispatcher, a Job, and other context elements. The dispatcher determines execution context, while the Job helps manage lifecycle and cancellation.
A custom scope can be created using a Job and a dispatcher. If you create a scope manually, you are responsible for cancelling it when the owning component is destroyed.
import kotlinx.coroutines.CoroutineScope
import kotlinx.coroutines.Dispatchers
import kotlinx.coroutines.Job
import kotlinx.coroutines.cancel
import kotlinx.coroutines.delay
import kotlinx.coroutines.launch
class BackgroundWorker {
private val workerJob = Job()
private val workerScope =
CoroutineScope(workerJob + Dispatchers.IO)
fun startWork() {
workerScope.launch {
delay(1000)
println("Background work completed")
}
}
fun stopWork() {
workerScope.cancel()
}
}This example creates a custom scope for background work. Calling stopWork() cancels the scope and its active child coroutines.
In real Android applications, prefer lifecycle-provided scopes whenever possible. Use custom scopes only when you need to manage work at a distinct lifecycle boundary.
A coroutine context is a collection of elements that describe how a coroutine runs. Common elements include:
import kotlinx.coroutines.CoroutineName
import kotlinx.coroutines.Dispatchers
import kotlinx.coroutines.launch
import kotlinx.coroutines.runBlocking
fun main() = runBlocking {
launch(
Dispatchers.Default + CoroutineName("DataProcessor")
) {
println("Processing data")
}
}The dispatcher controls execution, while the coroutine name helps identify the task during debugging. The plus operator combines context elements.
A Job represents the lifecycle of a coroutine. It can be used to observe completion, wait for work to finish, or cancel ongoing work.
import kotlinx.coroutines.Job
import kotlinx.coroutines.delay
import kotlinx.coroutines.launch
import kotlinx.coroutines.runBlocking
fun main() = runBlocking {
val task: Job = launch {
repeat(10) { index ->
delay(500)
println("Step: $index")
}
}
delay(1200)
task.cancel()
task.join()
println("Task cancelled")
}The coroutine performs repeated work with suspension points. After cancellation, it stops cooperatively and the program waits for its completion with join().
viewModelScope is a lifecycle-aware coroutine scope provided for Android ViewModels through AndroidX lifecycle libraries. Its coroutines are cancelled when the ViewModel is cleared.
import androidx.lifecycle.ViewModel
import androidx.lifecycle.viewModelScope
import kotlinx.coroutines.launch
class UserViewModel(
private val repository: UserRepository
) : ViewModel() {
fun loadUser(userId: Int) {
viewModelScope.launch {
try {
val user = repository.getUser(userId)
// Update observable UI state with user.
} catch (e: kotlinx.coroutines.CancellationException) {
throw e
} catch (e: Exception) {
// Update observable UI state with an error.
}
}
}
}This example assumes a UserRepository with a suspend function named getUser(). A production implementation should expose a UI state through StateFlow or another observable state holder.
lifecycleScope is associated with an Android LifecycleOwner, such as an Activity or Fragment. Its coroutines are cancelled when that lifecycle is destroyed.
import android.os.Bundle
import androidx.appcompat.app.AppCompatActivity
import androidx.lifecycle.lifecycleScope
import kotlinx.coroutines.launch
class MainActivity : AppCompatActivity() {
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
lifecycleScope.launch {
// Perform lifecycle-bound work.
}
}
}This scope is useful for operations directly associated with an Activity or Fragment lifecycle. However, a Fragment's view can be destroyed before the Fragment itself. For view-specific work, use the view lifecycle owner or another suitable lifecycle-aware approach.
| Scope | Lifecycle | Common Use |
|---|---|---|
| viewModelScope | Cancelled when the ViewModel is cleared. | Loading and managing screen data. |
| lifecycleScope | Cancelled when its LifecycleOwner is destroyed. | Lifecycle-bound Activity or Fragment tasks. |
| viewLifecycleOwner.lifecycleScope | Cancelled when the Fragment's view lifecycle is destroyed. | Work associated with a Fragment's view. |
| CoroutineScope(Job() + dispatcher) | Controlled manually by the owner. | Components that need a dedicated work lifecycle. |
| GlobalScope | Not automatically tied to a screen or component lifecycle. | Generally avoid for ordinary application work. |
Prefer lifecycle-aware scopes for normal Android features. A manually managed scope can be appropriate for a longer-lived component, but it must have a clear owner and cancellation strategy.
The withContext() function allows a coroutine to execute a block using a different coroutine context and returns the block's result after completion.
import kotlinx.coroutines.Dispatchers
import kotlinx.coroutines.withContext
suspend fun processData(): String {
val result = withContext(Dispatchers.Default) {
// Perform CPU-intensive processing.
"Processed data"
}
// Execution resumes in the original context.
return result
}This approach is useful when a function needs to perform work in another dispatcher without forcing its caller to manage the thread switch.
A main-safe function can be called from the main thread without blocking it. Repository and data-layer functions should handle their own dispatcher requirements when they perform blocking work.
class ReportRepository {
suspend fun createReport(records: List<Int>): Long {
return withContext(Dispatchers.Default) {
records.sumOf { it.toLong() }
}
}
}The caller can invoke createReport() from a main-thread coroutine without running the expensive calculation on the main thread.
Structured concurrency organizes related coroutines into a parent-child hierarchy. A parent coroutine normally waits for its children to finish, and cancellation of the parent propagates to its children.
This makes asynchronous operations easier to reason about because related work shares a clear lifecycle.
import kotlinx.coroutines.async
import kotlinx.coroutines.coroutineScope
suspend fun loadDashboard(): DashboardData = coroutineScope {
val profileTask = async {
api.getProfile()
}
val notificationsTask = async {
api.getNotifications()
}
DashboardData(
profile = profileTask.await(),
notifications = notificationsTask.await()
)
}This example assumes that api and DashboardData are defined elsewhere. The two requests are independent, so they can be started concurrently. The enclosing scope waits for its child operations to finish.
| Feature | coroutineScope() | CoroutineScope |
|---|---|---|
| Type | A suspending function that creates a structured scope. | An interface representing a coroutine context and lifecycle boundary. |
| Completion | Suspends until the block and its child coroutines complete. | Can be used to launch coroutines over the lifetime of its owner. |
| Typical purpose | Grouping related work inside a suspend function. | Managing coroutines in a component. |
| Cancellation | Participates in structured cancellation. | Its Job can be cancelled by the owner. |
Coroutine failures should be handled according to the operation and its scope. For example, a repository may convert network failures into a result type, while a ViewModel updates the UI with a friendly error message.
import kotlinx.coroutines.CancellationException
import kotlinx.coroutines.Dispatchers
import kotlinx.coroutines.withContext
suspend fun performCalculation(): Int {
return withContext(Dispatchers.Default) {
try {
calculateValue()
} catch (e: CancellationException) {
throw e
}
}
}The example rethrows cancellation instead of swallowing it. In a real application, catch only exceptions that you can meaningfully handle, and report expected failures through a suitable result or UI state.
| Mistake | Problem | Recommended Solution |
|---|---|---|
| Running heavy work on Dispatchers.Main | The interface may freeze. | Move CPU-intensive work to Dispatchers.Default. |
| Using Dispatchers.Default for blocking I/O | Blocking work may occupy computation threads. | Use Dispatchers.IO for blocking I/O operations. |
| Assuming suspend means background execution | A suspend function may execute on the current dispatcher. | Choose or switch dispatchers when required. |
| Creating a custom scope without cancelling it | Work may continue after its owner is destroyed. | Cancel the scope when the owner is finished. |
| Using GlobalScope for screen operations | Work can outlive the screen unnecessarily. | Prefer viewModelScope or lifecycleScope. |
| Updating views from a background thread | UI operations may fail or behave incorrectly. | Perform UI updates on Dispatchers.Main. |
| Using runBlocking on the main thread | The main thread is blocked until completion. | Use lifecycle-aware coroutine builders. |
| Swallowing CancellationException | Cancellation may not propagate correctly. | Rethrow cancellation. |
Create an Android application that retrieves data from an API, processes the response, and displays the result to the user.
viewModelScope to start the loading operation.After completing this project, you should understand how dispatchers determine execution context, how scopes manage coroutine lifecycles, and how repositories and ViewModels work together to support responsive Android applications.
Answer: A coroutine dispatcher determines the thread or thread pool used to execute coroutine code.
Answer: A CoroutineScope defines a coroutine context and provides a lifecycle boundary for launching and managing coroutines.
Answer: It is used for UI-related work on Android's main thread, including short operations that update views or UI state.
Answer: It is designed for blocking input/output operations such as file reads, file writes, and blocking I/O APIs.
Answer: It is designed for CPU-intensive computations, including large data transformations and expensive calculations.
Answer: It is a lifecycle-aware coroutine scope associated with a ViewModel. Its coroutines are cancelled when the ViewModel is cleared.
Answer: It is a coroutine scope associated with a LifecycleOwner and is cancelled when that owner's lifecycle is destroyed.
Answer: A dispatcher determines where coroutine code executes, while a scope defines the context and lifecycle within which coroutines are managed.
Answer: It executes a block in a specified coroutine context, suspends until the block completes, and returns its result.
Answer: Structured concurrency organizes related coroutines into a parent-child hierarchy so their completion, failure, and cancellation can be managed predictably.
Answer: Its work is not automatically tied to a screen or component lifecycle, so tasks may continue longer than necessary.
Answer: It allows coroutine cancellation to propagate correctly, helping stop work that is no longer needed.
Dispatchers and Coroutine Scopes are essential building blocks for managing asynchronous work in Android applications. Dispatchers determine where coroutine code runs, while scopes define how long related coroutines remain active and how they are cancelled.
By using Dispatchers.Main for UI work, Dispatchers.IO for blocking I/O, Dispatchers.Default for CPU-intensive tasks, and lifecycle-aware scopes such as viewModelScope and lifecycleScope, developers can build applications that are more responsive, maintainable, and reliable.
