Top 10 Coroutine Mistakes We All Have Made as Android Developers 관련

Android > Article(s)

---

Article(s)

• Introduction
• 1. Blocking the Main Thread
• 2. Ignoring Coroutine Scope Hierarchy
• 3. Mishandling Exception Propagation
• 4. Using the Wrong Coroutine Builder
• 5. Overusing GlobalScope
• 6. Not Considering Thread Safety
• 7. Forgetting to Cancel Coroutines
• 8. Blocking Inside Coroutines
• 9. MisusingwithContext
• 10. Not Testing Coroutines Properly

---

Top 10 Coroutine Mistakes We All Have Made as Android Developers

As Android developers, Kotlin coroutines have become an indispensable tool in our asynchronous programming toolkit. They simplify concurrent tasks, make code more readable, and help us avoid the callback hell that was prevalent with earlier approaches. However, coroutines come with their own set of challenges, and it’s easy to fall into common pitfalls that can lead to bugs, crashes, or suboptimal performance.

Introduction

As Android developers, Kotlin coroutines have become an indispensable tool in our asynchronous programming toolkit. They simplify concurrent tasks, make code more readable, and help us avoid the callback hell that was prevalent with earlier approaches. However, coroutines come with their own set of challenges, and it’s easy to fall into common pitfalls that can lead to bugs, crashes, or suboptimal performance.

In this article, we’ll explore the top 10 coroutine mistakes that many of us have made (often unknowingly) and provide guidance on how to avoid them. Whether you’re a seasoned developer or just starting with coroutines, this guide aims to enhance your understanding and help you write more robust asynchronous code.

---

1. Blocking the Main Thread

The Mistake

Running long-running or blocking tasks on theMaindispatcher, which can freeze the UI and lead to Application Not Responding (ANR) errors.

Why It Happens

It’s easy to forget which dispatcher is being used, especially in complex codebases. Developers might launch a coroutine without specifying a dispatcher, inadvertently using theMaindispatcher by default.

How to Avoid It

Always specify the appropriate dispatcher for your coroutine:

Example

// Wrong
GlobalScope.launch {
    // Long-running task
}

// Correct
GlobalScope.launch(Dispatchers.IO) {
    // Long-running task
}

UseDispatchers.IOfor I/O operations andDispatchers.Defaultfor CPU-intensive tasks. ReserveDispatchers.Mainfor updating the UI.

---

2. Ignoring Coroutine Scope Hierarchy

The Mistake

Not properly structuring coroutine scopes, leading to unmanaged coroutines that outlive their intended lifecycle, causing memory leaks or crashes.

Why It Happens

UsingGlobalScopeindiscriminately or failing to cancel coroutines when a component is destroyed.

How to Avoid It

Use structured concurrency by tying coroutines to a specific lifecycle:

• In activities or fragments, uselifecycleScopeorviewLifecycleOwner.lifecycleScope.
• In ViewModels, useviewModelScope.

Example

// In a ViewModel
viewModelScope.launch {
    // Coroutine work
}

This ensures that coroutines are cancelled appropriately when the associated lifecycle is destroyed.

---

3. Mishandling Exception Propagation

The Mistake

Failing to handle exceptions within coroutines properly, which can cause unexpected crashes or silent failures.

Why It Happens

Assuming thattry-catchblocks will work the same way inside coroutines or not understanding how exceptions propagate in coroutine hierarchies.

How to Avoid It

• Usetry-catchwithin the coroutine to handle exceptions. Be cautious to check forCancellationException, as it’s used to signal coroutine cancellation, and should typically be rethrown to allow the coroutine to cancel properly.
• For structured concurrency, exceptions in child coroutines are propagated to the parent.

Example

viewModelScope.launch {
    try {
        // Suspended function that might throw an exception
    } catch (e: Exception) {
        if (e !is CancellationException) {
            // Handle exception
        } else {
            throw e // Rethrow to respect cancellation
        }
    }
}

Alternatively, use aCoroutineExceptionHandlerfor unhandled exceptions:

val exceptionHandler = CoroutineExceptionHandler { \_, throwable ->
    if (throwable !is CancellationException) {
        // Handle unhandled exception
    }
}

viewModelScope.launch(exceptionHandler) {
    // Suspended function that might throw an exception
}

---

4. Using the Wrong Coroutine Builder

The Mistake

Confusinglaunchandasyncbuilders, leading to unintended behavior, such as missing results or unnecessary concurrency.

Why It Happens

Misunderstanding the difference betweenlaunch(which returnsJob) andasync(which returnsDeferredand is meant for obtaining a result).

How to Avoid It

• Uselaunchwhen you don’t need a result and want to fire off a coroutine.
• Useasyncwhen you need to compute a value asynchronously.

Example

// Using async when you need a result
val deferredResult = async {
    computeValue()
}
val result = deferredResult.await()

---

5. Overusing GlobalScope

The Mistake

Relying onGlobalScopefor launching coroutines, which can lead to coroutines that run longer than needed and are difficult to manage.

Why It Happens

Forgetting to consider the coroutine’s lifecycle or for the sake of simplicity in examples and tutorials.

How to Avoid It

AvoidGlobalScopeunless absolutely necessary. Instead, use structured concurrency with appropriate scopes:

• lifecycleScopefor UI-related components.
• viewModelScopefor ViewModels.
• CustomCoroutineScopewith proper cancellation.

---

6. Not Considering Thread Safety

The Mistake

Accessing or modifying shared mutable data from multiple coroutines without proper synchronization, leading to race conditions.

Why It Happens

Assuming that coroutines handle threading for you and neglecting the need for thread safety in shared resources.

How to Avoid It

• Use thread-safe data structures.
• Synchronize access withMutexorAtomicclasses.
• Confine mutable state to specific threads or coroutines.

Example usingMutex

val mutex = Mutex()
var sharedResource = 0

coroutineScope.launch {
    mutex.withLock {
        sharedResource++
    }
}

---

7. Forgetting to Cancel Coroutines

The Mistake

Not cancelling coroutines when they’re no longer needed, which can waste resources or cause unintended side effects.

Why It Happens

Overlooking cancellation logic or not handling it properly in custom scopes.

How to Avoid It

• Use structured concurrency so that coroutines are cancelled automatically.
• When using custom scopes, ensure that you cancel them at the appropriate time.

Example

val job = CoroutineScope(Dispatchers.IO).launch {
    // Work
}

// Cancel when done
job.cancel()

---

8. Blocking Inside Coroutines

The Mistake

Using blocking calls likeThread.sleep()or heavy computations inside coroutines without switching to an appropriate dispatcher, which can block the underlying thread.

Why It Happens

Misunderstanding that coroutines are lightweight threads and thinking that blocking operations are safe within them.

How to Avoid It

• Avoid blocking calls inside coroutines.
• Use suspend functions likedelay()instead ofThread.sleep().
• Offload heavy computations toDispatchers.Default.

Example

// Wrong
launch(Dispatchers.IO) {
    Thread.sleep(1000)
}

// Correct
launch(Dispatchers.IO) {
    delay(1000)
}

---

9. MisusingwithContext

The Mistake

UsingwithContextincorrectly, such as nesting it unnecessarily or misunderstanding its purpose, leading to code that’s hard to read or inefficient.

Why It Happens

Confusion about context switching and the scope ofwithContext.

How to Avoid It

• UsewithContextto switch the context for a specific block of code.
• Don’t nestwithContextcalls without need.
• KeepwithContextblocks as small as possible.

Example

// Correct usage
val result = withContext(Dispatchers.IO) {
    // Perform I/O operation
}

---

10. Not Testing Coroutines Properly

The Mistake

Neglecting to write proper tests for coroutine-based code, or writing tests that don’t handle coroutines correctly, leading to flaky or unreliable tests.

Why It Happens

Testing asynchronous code is more complex, and developers might not be familiar with the testing tools available for coroutines.

How to Avoid It

• UserunBlockingTestorrunTestfromkotlinx-coroutines-testfor unit testing coroutines.
• LeverageTestCoroutineDispatcherandTestCoroutineScopeto control coroutine execution in tests.
• Ensure that you advance time properly when testing code with delays or timeouts.

Example

@Test
fun testCoroutine() = runTest {
    val result = mySuspendingFunction()
    assertEquals(expectedResult, result)
}

---

Conclusion

Coroutines are powerful, but with great power comes great responsibility. By being aware of these common mistakes and understanding how to avoid them, you can write more efficient, reliable, and maintainable asynchronous code in your Android applications.

Remember:

• Always choose the correct dispatcher.
• Tie your coroutines to the appropriate lifecycle.
• Handle exceptions thoughtfully.
• Be mindful of coroutine scopes and cancellation.
• Test your coroutine code thoroughly.

By following these best practices, you’ll harness the full potential of Kotlin coroutines and provide a smoother, more responsive experience for your app users.

Dobri Kostadinov

Android Consultant | Trainer

Email me|Follow me on LinkedIn (dobrikostadinov)|Follow me on Medium (dobri.kostadinov)|Buy me a coffee

Info

This article is previously published on proandroiddev

Top 10 Coroutine Mistakes We All Have Made as Android Developers

Understanding and Avoiding Common Pitfalls in Asynchronous Programming with Kotlin Coroutines

Top 10 Coroutine Mistakes We All Have Made as Android Developers

---

As Android developers, Kotlin coroutines have become an indispensable tool in our asynchronous programming toolkit. They simplify concurrent tasks, make code more readable, and help us avoid the callback hell that was prevalent with earlier approaches. However, coroutines come with their own set of challenges, and it’s easy to fall into common pitfalls that can lead to bugs, crashes, or suboptimal performance.