What if you could send one message and have everyone hear it instantly without extra work?
Why SharedFlow for event broadcasting in Kotlin? - Purpose & Use Cases
Imagine you have a group chat where you want to share a message with everyone instantly. Doing this by sending individual texts to each person one by one is tiring and slow.
Manually sending events to multiple listeners means writing repetitive code, risking missed messages, and struggling to keep everyone updated at the same time.
SharedFlow acts like a broadcast channel where one message is sent once and all listeners receive it instantly, making event sharing smooth and reliable.
fun sendEventToListeners(event: String, listeners: List<(String) -> Unit>) {
for (listener in listeners) {
listener(event)
}
}val sharedFlow = MutableSharedFlow<String>()
suspend fun broadcastEvent(event: String) {
sharedFlow.emit(event)
}
// Collecting from sharedFlow should be done in a coroutine
// Example:
// CoroutineScope(Dispatchers.Main).launch {
// sharedFlow.collect { event -> println("Received: $event") }
// }It enables efficient, real-time event broadcasting to many receivers without complex manual handling.
In a chat app, when one user sends a message, SharedFlow broadcasts it instantly to all active users without delay or missed updates.
Manual event sending is slow and error-prone.
SharedFlow broadcasts events to many listeners efficiently.
This makes real-time communication smooth and reliable.
Practice
SharedFlow in Kotlin?Solution
Step 1: Understand SharedFlow's role
SharedFlow is designed to send events to many listeners at once, like a radio broadcast.Step 2: Compare with other options
It does not store data permanently, perform heavy computations, or create single-threaded queues.Final Answer:
To broadcast events to multiple listeners simultaneously -> Option AQuick Check:
SharedFlow = Broadcast events [OK]
- Confusing SharedFlow with data storage
- Thinking SharedFlow handles computations
- Assuming SharedFlow is single-threaded queue
SharedFlow with replay of 2 events?Solution
Step 1: Recall SharedFlow creation syntax
MutableSharedFlow constructor uses parameterreplayto set how many past events to keep.Step 2: Check options for correct parameter
Only val flow = MutableSharedFlow<Int>(replay = 2) usesreplay = 2correctly. Others use wrong parameter names or types.Final Answer:
val flow = MutableSharedFlow<Int>(replay = 2) -> Option BQuick Check:
Use replay parameter to set past events [OK]
- Using SharedFlow instead of MutableSharedFlow for creation
- Wrong parameter names like bufferSize or replayCount
- Confusing replay with buffer
val flow = MutableSharedFlow<Int>(replay = 1)
suspend fun main() {
flow.emit(10)
flow.emit(20)
flow.collect { value ->
println(value)
}
}Solution
Step 1: Understand replay behavior
Withreplay = 1, only the last emitted value is kept for new collectors.Step 2: Analyze emitted values and collection
Values 10 and 20 are emitted, but only 20 is replayed to the collector.Final Answer:
20 -> Option CQuick Check:
Replay 1 means last event only [OK]
- Expecting all emitted values to be replayed
- Confusing replay with buffer size
- Thinking collector receives events emitted before subscription
val flow = MutableSharedFlow<Int>()
suspend fun main() {
flow.collect { println(it) }
flow.emit(5)
}Solution
Step 1: Understand collect and emit behavior
collect is a suspending function that waits for events and blocks until cancelled.Step 2: Analyze code flow
Since collect is called first and blocks, emit is never reached. emit must be called concurrently.Final Answer:
collect should be launched in a separate coroutine -> Option AQuick Check:
collect blocks; emit needs separate coroutine [OK]
- Calling emit after collect in same coroutine
- Assuming emit runs before collect automatically
- Thinking replay parameter is mandatory
SharedFlow. Which approach correctly ensures all components receive the latest 3 clicks even if they subscribe late?Solution
Step 1: Identify replay requirement
Replay of 3 means new subscribers get last 3 events automatically.Step 2: Match with SharedFlow usage
MutableSharedFlow withreplay = 3fits perfectly for broadcasting recent events to multiple listeners.Step 3: Evaluate other options
MutableStateFlow holds only one value, Channel does not replay past events, List is manual and not reactive.Final Answer:
Create a MutableSharedFlow with replay = 3 and emit clicks; components collect from it -> Option DQuick Check:
Replay 3 in SharedFlow broadcasts last 3 events [OK]
- Using StateFlow which holds only one value
- Using Channel which doesn't replay past events
- Manually managing event lists instead of reactive streams
Ready to prove it?
Pass the test and this pattern moves unknown
