launch and async builders in Android Kotlin - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ ui_behavior

intermediate

What happens when using launch in a CoroutineScope?

Consider this Kotlin code snippet inside an Android activity:

lifecycleScope.launch {
  delay(1000)
  textView.text = "Hello"
}

What will the user see immediately after this code runs?

Android Kotlin

lifecycleScope.launch {
  delay(1000)
  textView.text = "Hello"
}

A The textView updates to "Hello" after 1 second delay.

B The app crashes because delay cannot be used here.

C The textView updates immediately without delay.

D The textView never updates because launch does not run.

💡 Hint

launch starts a coroutine that runs asynchronously and can delay without blocking the main thread.

The launch builder starts a coroutine that runs asynchronously. The delay suspends the coroutine for 1 second without blocking the UI thread. After the delay, the textView text is updated.

🧠 Conceptual

intermediate

Difference between launch and async builders?

Which statement correctly describes the difference between launch and async coroutine builders in Kotlin?

A launch can only be used in background threads; async only on main thread.

B launch returns a Job and does not produce a result; async returns a Deferred and produces a result.

C launch blocks the thread; async runs asynchronously without blocking.

D launch returns a Deferred; async returns a Job.

💡 Hint

Think about which builder lets you get a result back.

launch starts a coroutine and returns a Job, which represents the coroutine but does not produce a result. async starts a coroutine and returns a Deferred, which is a future result you can await.

📝 Syntax

advanced

What is the output of this async coroutine code?

Given this Kotlin code snippet:

val deferred = lifecycleScope.async {
  delay(500)
  42
}

val result = runBlocking {
  deferred.await()
}
println(result)

What will be printed?

Android Kotlin

val deferred = lifecycleScope.async {
  delay(500)
  42
}

val result = runBlocking {
  deferred.await()
}
println(result)

A The code never prints because of deadlock.

B 0

C The code throws an exception because await is called outside coroutine.

D 42

💡 Hint

await waits for the async coroutine to finish and returns its result.

The async builder returns a Deferred that produces 42 after 500ms delay. runBlocking waits for deferred.await() to complete and returns 42, which is printed.

❓ lifecycle

advanced

What happens if you launch a coroutine in lifecycleScope after onDestroy?

In an Android activity, what happens if you call lifecycleScope.launch { /* some code */ } after the onDestroy() method has been called?

A The coroutine is immediately cancelled and does not run.

B The coroutine runs normally even after onDestroy.

C The app crashes with IllegalStateException.

D The coroutine runs but leaks memory.

💡 Hint

lifecycleScope is tied to the lifecycle and cancels coroutines when destroyed.

lifecycleScope is cancelled when the lifecycle owner is destroyed. Launching a coroutine after onDestroy means the scope is cancelled, so the coroutine is immediately cancelled and does not run.

🔧 Debug

expert

Why does this async coroutine code cause a deadlock?

Analyze this Kotlin code snippet:

val deferred = lifecycleScope.async {
  delay(1000)
  10
}

val result = deferred.await()
println(result)

Why might this code cause the app to freeze or deadlock?

Android Kotlin

val deferred = lifecycleScope.async {
  delay(1000)
  10
}

val result = deferred.await()
println(result)

A Because lifecycleScope.async returns null causing NullPointerException.

B Because delay cannot be used inside async builder.

C Because await is called on the main thread blocking it, preventing async from completing.

D Because println blocks the coroutine indefinitely.

💡 Hint

Consider what happens when you block the main thread waiting for a coroutine that also runs on the main thread.

Calling deferred.await() on the main thread blocks it. Since lifecycleScope.async runs on the main thread by default, the coroutine cannot resume to complete, causing a deadlock.