SharedFlow for events in Android Kotlin - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ ui_behavior

intermediate

What happens when multiple collectors subscribe to a SharedFlow?

Consider a SharedFlow that emits integer events. If two collectors start collecting from this SharedFlow, what will they receive?

Android Kotlin

val sharedFlow = MutableSharedFlow<Int>()

// Collector 1
sharedFlow.onEach { println("Collector 1 received: $it") }.launchIn(scope)

// Collector 2
sharedFlow.onEach { println("Collector 2 received: $it") }.launchIn(scope)

sharedFlow.emit(5)

A Only the first collector receives the event 5.

B Both collectors receive the event 5.

C Only the second collector receives the event 5.

D Neither collector receives the event 5.

💡 Hint

SharedFlow is designed to broadcast events to all active collectors.

A SharedFlow emits events to all collectors that are actively collecting. So when you emit 5, both collectors receive it.

❓ lifecycle

intermediate

How does SharedFlow behave when collectors start after emission?

If a MutableSharedFlow is created with default settings and an event is emitted before any collector starts, what happens when a collector starts collecting later?

Android Kotlin

val sharedFlow = MutableSharedFlow<Int>()

sharedFlow.emit(10)

// Collector starts after emit
sharedFlow.onEach { println("Received: $it") }.launchIn(scope)

A The collector receives a default value 0.

B The code throws an exception.

C The collector does not receive the event 10.

D The collector receives the event 10.

💡 Hint

Default SharedFlow does not replay events to late collectors.

By default, MutableSharedFlow does not replay past events to new collectors. So if the event was emitted before collecting started, the collector misses it.

📝 Syntax

advanced

What is the correct way to create a SharedFlow that replays the last event?

You want a SharedFlow that replays the last emitted event to new collectors. Which code snippet correctly creates such a SharedFlow?

A val sharedFlow = MutableSharedFlow<Int>(replay = 1)

B val sharedFlow = MutableSharedFlow<Int>(bufferSize = 1)

C val sharedFlow = MutableSharedFlow<Int>(cache = 1)

D val sharedFlow = MutableSharedFlow<Int>(replayCount = 1)

💡 Hint

The parameter to control replay is named 'replay'.

The replay parameter sets how many past events are replayed to new collectors. The correct parameter name is replay.

🔧 Debug

advanced

Why does this SharedFlow emit block suspend indefinitely?

Given this code, why does the call to emit suspend forever?

Android Kotlin

val sharedFlow = MutableSharedFlow<Int>(replay = 0, extraBufferCapacity = 0)

// No collectors started
sharedFlow.emit(1) // Suspends here

A Because emit requires at least one collector to be started before calling.

B Because replay is zero, emit cannot send events.

C Because extraBufferCapacity is zero, emit throws an exception.

D Because there is no buffer and no active collectors, emit suspends waiting for a collector.

💡 Hint

Emit suspends if there is no buffer and no collector to receive the event.

When replay and extraBufferCapacity are zero, emit suspends until a collector is ready to receive the event.

🧠 Conceptual

expert

How to ensure events are not lost when no collectors are active?

You want to use a SharedFlow to send UI events that must not be lost even if no collector is active at the moment of emission. Which configuration ensures this behavior?

A Create MutableSharedFlow with replay = 1 and extraBufferCapacity = 1.

B Create MutableSharedFlow with replay = 0 and extraBufferCapacity = 1.

C Create MutableSharedFlow with replay = 1 and extraBufferCapacity = 0.

D Create MutableSharedFlow with replay = 0 and extraBufferCapacity = 0.

💡 Hint

Replay buffers past events; extraBufferCapacity buffers new events when no collector is ready.

Setting replay = 1 keeps the last event for new collectors. Setting extraBufferCapacity = 1 allows buffering one event when no collector is active, preventing suspension or loss.

Practice

1. What is the primary purpose of using SharedFlow in Android Kotlin apps?

easy

A. To manage background threads automatically

B. To store large amounts of data persistently

C. To send events to multiple listeners safely and efficiently

D. To replace all UI components with reactive streams

Solution

1. Step 1: Understand SharedFlow's role

   SharedFlow is designed to broadcast events to multiple collectors without losing any events.

2. Step 2: Compare with other options

   It is not for data storage, UI replacement, or thread management.

3. Final Answer:

   To send events to multiple listeners safely and efficiently -> Option C

4. Quick Check:

   SharedFlow = event broadcasting [OK]

Hint: SharedFlow broadcasts events to many listeners [OK]

Common Mistakes:

• Confusing SharedFlow with data storage solutions
• Thinking SharedFlow manages threads automatically
• Assuming SharedFlow replaces UI components

2. Which of the following is the correct way to emit an event using a MutableSharedFlow named eventFlow?

easy

A. eventFlow.emit("New Event")

B. eventFlow.collect { "New Event" }

C. eventFlow.send("New Event")

D. eventFlow.postValue("New Event")

Solution

1. Step 1: Identify the correct emission method

   MutableSharedFlow uses emit() to send events.

2. Step 2: Eliminate incorrect methods

   collect() is for receiving, send() is for Channels, and postValue() is for LiveData.

3. Final Answer:

   eventFlow.emit("New Event") -> Option A

4. Quick Check:

   Emit events with emit() [OK]

Hint: Use emit() to send events on SharedFlow [OK]

Common Mistakes:

• Using collect() to send events
• Confusing SharedFlow with Channel's send()
• Using LiveData's postValue() with SharedFlow

3. Given the following code snippet, what will be printed when the event is emitted?

val eventFlow = MutableSharedFlow<String>()

fun observe() {
  eventFlow.collect { println(it) }
}

fun sendEvent() {
  eventFlow.emit("Hello")
}

sendEvent()
observe()

medium

A. Compilation error

B. Hello printed twice

C. No output

D. Hello

Solution

1. Step 1: Analyze suspend function calls

   Both emit() and collect() are suspend functions called from non-suspend functions and top-level code without a coroutine scope.

2. Step 2: Result of invalid calls

   Suspend functions cannot be called from non-suspend contexts, causing a compilation error.

3. Final Answer:

   Compilation error -> Option A

4. Quick Check:

   suspend emit/collect outside coroutine = compile error [OK]

Hint: emit() and collect() must be called in coroutines [OK]

Common Mistakes:

• Overlooking that emit() and collect() are suspend functions
• Assuming the code compiles and runs to test replay behavior
• Forgetting coroutine requirements for Flow operations

4. Identify the problem in this code snippet using SharedFlow:

val eventFlow = MutableSharedFlow<String>()

fun start() {
  eventFlow.emit("Start")
}

fun listen() {
  eventFlow.collect { println(it) }
}

start()
listen()

medium

A. No problem, code works fine

B. collect() is called without a coroutine

C. MutableSharedFlow cannot emit strings

D. emit() is called outside a coroutine

Solution

1. Step 1: Check emit() usage

   emit() is a suspend function and must be called inside a coroutine.

2. Step 2: Check collect() usage

   collect() is also suspend and needs a coroutine, but the question focuses on emit() first.

3. Final Answer:

   emit() is called outside a coroutine -> Option D

4. Quick Check:

   emit() requires coroutine context [OK]

Hint: emit() must run inside a coroutine [OK]

Common Mistakes:

• Calling emit() directly without coroutine
• Ignoring suspend nature of collect()
• Thinking MutableSharedFlow restricts data types

5. You want to show a toast message every time a button is clicked using SharedFlow. Which approach correctly ensures the toast shows for each click even if the UI is recreated?

hard

A. Use a MutableSharedFlow with no replay and emit on button click

B. Use a MutableSharedFlow with replay = 1 and emit on button click

C. Use a StateFlow to hold the last toast message and emit on button click

D. Use LiveData to send the toast message on button click

Solution

1. Step 1: Understand event replay needs

   To show toast after UI recreation, events must replay at least once.

2. Step 2: Choose correct flow type and replay

   MutableSharedFlow with replay=1 replays last event to new collectors, ensuring toast shows.

3. Step 3: Compare other options

   No replay means missed events; StateFlow holds state, not events; LiveData is not SharedFlow.

4. Final Answer:

   Use a MutableSharedFlow with replay = 1 and emit on button click -> Option B

5. Quick Check:

   Replay 1 ensures event delivery after UI recreation [OK]

Hint: Set replay=1 to resend last event to new collectors [OK]

Common Mistakes:

• Using no replay and missing events after UI changes
• Confusing StateFlow state with event replay
• Using LiveData instead of SharedFlow for events