Why coroutines simplify async programming in Android Kotlin - Challenge Your Understanding

Challenge - 5 Problems

🧠 Conceptual

intermediate

Why are coroutines preferred over callbacks for async tasks?

Which of the following best explains why coroutines simplify asynchronous programming compared to traditional callbacks?

A Coroutines automatically run all code on the main thread, avoiding thread switching.

B Coroutines block the main thread until the async task finishes, ensuring synchronous behavior.

C Coroutines require no imports or setup, unlike callbacks.

D Coroutines allow writing asynchronous code sequentially, making it easier to read and maintain.

💡 Hint

Think about how code looks and feels when using coroutines versus callbacks.

Coroutines let you write async code that looks like normal sequential code, avoiding nested callbacks and making it easier to understand and maintain.

❓ ui_behavior

intermediate

Effect of coroutine on UI responsiveness

What happens to the UI when a long-running task is launched inside a coroutine with Dispatchers.IO in Android?

A The UI remains responsive because the task runs on a background thread.

B The UI crashes due to thread violation errors.

C The UI freezes because the coroutine blocks the main thread.

D The UI updates immediately before the task finishes.

💡 Hint

Consider which thread Dispatchers.IO uses.

Dispatchers.IO runs coroutines on a background thread pool, so the UI thread is free and remains responsive during long tasks.

❓ lifecycle

advanced

Coroutine cancellation and Android lifecycle

What is the correct behavior when a coroutine launched in a ViewModelScope is cancelled due to ViewModel clearing?

A The coroutine is automatically cancelled to avoid memory leaks.

B The coroutine continues running even after ViewModel is cleared.

C The coroutine throws an exception that crashes the app.

D The coroutine restarts automatically when ViewModel is recreated.

💡 Hint

Think about how ViewModelScope manages coroutines with lifecycle.

ViewModelScope cancels all its coroutines when the ViewModel is cleared, preventing work from continuing unnecessarily and avoiding leaks.

❓ navigation

advanced

Handling coroutine results for navigation

In an Android app, which coroutine approach correctly waits for a network call result before navigating to the next screen?

Android Kotlin

fun onButtonClick() {
  lifecycleScope.launch {
    val data = fetchData() // suspend function
    navigateToNextScreen(data)
  }
}

A Use GlobalScope.launch and navigate inside fetchData function.

B Call navigateToNextScreen immediately after launching the coroutine without waiting.

C Launch a coroutine and call navigateToNextScreen only after fetchData returns.

D Run fetchData on the main thread without coroutine.

💡 Hint

Consider when the navigation happens relative to the suspend function completion.

Launching a coroutine and awaiting fetchData ensures navigation happens only after data is ready, preventing errors or blank screens.

📝 Syntax

expert

Correct syntax for launching a coroutine with exception handling

Which Kotlin coroutine code snippet correctly launches a coroutine and catches exceptions without blocking the main thread?

Android Kotlin

val handler = CoroutineExceptionHandler { _, exception -> println("Error: $exception") }
lifecycleScope.launch(handler) {
  // some suspend function call
}

A lifecycleScope.launch { try { someSuspendFunction() } catch (e: Exception) { println(e) } }

B lifecycleScope.launch(handler) { someSuspendFunction() }

C lifecycleScope.launch { someSuspendFunction() } catch (e: Exception) { println(e) }

D lifecycleScope.launch(handler) someSuspendFunction()

💡 Hint

Look for correct placement of CoroutineExceptionHandler and syntax.

Option B correctly attaches CoroutineExceptionHandler to the coroutine builder and calls the suspend function inside the coroutine block.