Beyond launch and async
Most Android developers learn coroutines by calling `launch` inside a `viewModelScope` and moving on. This works for basic cases, but production apps need more. You need to understand how coroutines relate to each other through structured concurrency, how cancellation propagates, and how exceptions bubble up through the coroutine hierarchy.
Structured concurrency is the principle that a coroutine's lifetime is bound to its scope. When a scope is cancelled, every coroutine launched within it is cancelled too. This prevents resource leaks and orphaned background work -- problems that plagued the old AsyncTask and thread-based approaches.
Coroutine Scopes and Their Lifecycle
Every coroutine runs inside a CoroutineScope. Android provides lifecycle-aware scopes through Jetpack, including `viewModelScope` which is the most commonly used:
- `viewModelScope`: cancelled when the ViewModel is cleared
- `lifecycleScope`: cancelled when the Lifecycle is destroyed
- `rememberCoroutineScope()`: cancelled when the composable leaves composition
The scope determines when your coroutines stop. Using the wrong scope is a common source of bugs. A network request launched in `lifecycleScope` will be cancelled on configuration changes (screen rotation), potentially losing the response. The same request in `viewModelScope` survives rotation because the ViewModel outlives the Activity.
kotlin
class SearchViewModel(
private val searchRepo: SearchRepository
) : ViewModel() {
private val _results = MutableStateFlow<List<Result>>(emptyList())
val results: StateFlow<List<Result>> = _results.asStateFlow()
// viewModelScope survives configuration changes
fun search(query: String) {
viewModelScope.launch {
// This coroutine is automatically cancelled when
// the ViewModel is cleared (user leaves the screen)
_results.value = searchRepo.search(query)
}
}
}
// In a Composable:
@Composable
fun SearchScreen(viewModel: SearchViewModel) {
// rememberCoroutineScope ties to composition lifecycle
val scope = rememberCoroutineScope()
// Use for UI-only work like animations or snackbars
scope.launch {
snackbarHostState.showSnackbar("Search complete")
}
}Cancellation: The Silent Contract
Cancellation is cooperative in Kotlin coroutines. Calling `cancel()` on a job doesn't immediately stop execution -- it sets a flag that suspending functions check. Functions like `delay()`, `withContext()`, and `yield()` check for cancellation and throw `CancellationException` if the coroutine is cancelled.
The practical implication: if your coroutine does CPU-intensive work without calling any suspending function, it won't respond to cancellation. You need to check manually with `ensureActive()` or `isActive`.
kotlin
// BAD: This loop ignores cancellation
suspend fun processLargeList(items: List<Item>) {
for (item in items) {
item.transform() // CPU work, no suspension point
}
}
// GOOD: Check for cancellation in tight loops
suspend fun processLargeList(items: List<Item>) {
for (item in items) {
ensureActive() // Throws if cancelled
item.transform()
}
}
// GOOD: Use yield() to check cancellation and give
// other coroutines a chance to run
suspend fun processLargeList(items: List<Item>) {
for (item in items) {
yield()
item.transform()
}
}Exception Handling Strategies
Exception handling in coroutines is the area where most developers make mistakes. The rules differ between `launch` and `async`, and between regular coroutines and SupervisorJob scopes.
With `launch`, uncaught exceptions propagate up to the parent scope and cancel all sibling coroutines. This is usually not what you want -- one failed API call shouldn't cancel every other running operation.
With `async`, exceptions are deferred until you call `await()`. This gives you a chance to handle them at the call site. `SupervisorJob` changes the propagation behavior so that one child's failure doesn't cancel siblings.
kotlin
// PROBLEM: One failure cancels everything
viewModelScope.launch {
launch { loadUserProfile() } // If this throws...
launch { loadUserPosts() } // ...this gets cancelled
launch { loadUserSettings() } // ...and this too
}
// SOLUTION: supervisorScope isolates failures
viewModelScope.launch {
supervisorScope {
launch {
try { loadUserProfile() }
catch (e: Exception) { handleProfileError(e) }
}
launch {
try { loadUserPosts() }
catch (e: Exception) { handlePostsError(e) }
}
launch {
try { loadUserSettings() }
catch (e: Exception) { handleSettingsError(e) }
}
}
}
// ALTERNATIVE: CoroutineExceptionHandler at the top level
val handler = CoroutineExceptionHandler { _, exception ->
analytics.logError(exception)
}
viewModelScope.launch(handler + SupervisorJob()) {
launch { loadUserProfile() }
launch { loadUserPosts() }
}Flow: Reactive Streams Done Right
Kotlin Flow is the coroutine-based replacement for RxJava's Observable. It provides a cold, asynchronous stream of values with built-in cancellation support and backpressure handling.
The most important Flow operators for Android development are `map`, `filter`, `combine`, `flatMapLatest`, and `debounce`. Understanding when to use each prevents common bugs like stale search results or duplicate API calls.
kotlin
class SearchViewModel(
private val repo: SearchRepository
) : ViewModel() {
private val _query = MutableStateFlow("")
// debounce + flatMapLatest: classic search pattern
val results: StateFlow<SearchState> = _query
.debounce(300) // Wait 300ms after last keystroke
.filter { it.length >= 2 } // Min query length
.flatMapLatest { query ->
// Cancels previous search when new query arrives
flow {
emit(SearchState.Loading)
try {
val results = repo.search(query)
emit(SearchState.Success(results))
} catch (e: Exception) {
emit(SearchState.Error(e.message))
}
}
}
.stateIn(
scope = viewModelScope,
started = SharingStarted.WhileSubscribed(5000),
initialValue = SearchState.Idle
)
fun onQueryChanged(query: String) {
_query.value = query
}
}
sealed interface SearchState {
data object Idle : SearchState
data object Loading : SearchState
data class Success(val results: List<Result>) : SearchState
data class Error(val message: String?) : SearchState
}Testing Coroutines
Testing coroutines requires controlling the dispatcher to make asynchronous code behave synchronously in tests. The `kotlinx-coroutines-test` library provides `runTest`, `TestDispatcher`, and `advanceUntilIdle()` to achieve this.
The key principle: replace `Dispatchers.IO` and `Dispatchers.Main` with a `TestDispatcher` in your tests. Inject dispatchers rather than hardcoding them, and your coroutine code becomes fully testable.
kotlin
class SearchViewModelTest {
private val testDispatcher = UnconfinedTestDispatcher()
@Before
fun setup() {
Dispatchers.setMain(testDispatcher)
}
@After
fun tearDown() {
Dispatchers.resetMain()
}
@Test
fun `search emits loading then results`() = runTest {
val fakeRepo = FakeSearchRepository(
results = listOf(Result("Kotlin"))
)
val viewModel = SearchViewModel(fakeRepo)
viewModel.onQueryChanged("Kotlin")
advanceUntilIdle()
val state = viewModel.results.value
assertIs<SearchState.Success>(state)
assertEquals(1, state.results.size)
}
}Key Takeaways
- 1Structured concurrency binds coroutine lifetime to scope -- preventing leaks automatically.
- 2Use viewModelScope for data operations, rememberCoroutineScope for UI-only work.
- 3Cancellation is cooperative: check ensureActive() in CPU-intensive loops.
- 4Use supervisorScope to isolate failures between independent operations.
- 5flatMapLatest + debounce is the canonical pattern for search-as-you-type.
- 6Inject dispatchers for testability -- never hardcode Dispatchers.IO.
Frequently Asked
What's the difference between launch and async?
launch returns Job for fire-and-forget. async returns Deferred<T> for results. Always call await() on Deferred to get results or propagate exceptions.
How do I handle exceptions in coroutines?
Use try/catch inside coroutines for local handling. Use CoroutineExceptionHandler for global handling. For async, exceptions propagate on await().
Flow vs StateFlow - when to use which?
Flow for cold streams starting fresh per collector. StateFlow for hot streams maintaining state and replaying latest value to new collectors.
Ready to architect your next Android app?
ANDROID-ARCHITECT generates production-ready Kotlin code, architecture blueprints, and CI/CD configurations from plain-language descriptions. Start building for free.
ANDROID-ARCHITECT · CONSOLE
S/N · AX-1A-00001
STRATEGIA-X · ENGINEERED · IN · CALIFORNIA