SharedFlow for events in Android Kotlin - Cheat Sheet & Quick Revision

Recall & Review

beginner

What is SharedFlow in Kotlin?

SharedFlow is a hot flow that allows multiple collectors to receive the same emitted values. It is useful for sharing events or data streams across different parts of an app.

intermediate

Why use SharedFlow for events instead of StateFlow?

SharedFlow is better for one-time events because it can replay a configurable number of past events and does not hold a current state like StateFlow. StateFlow always holds the latest value, which is not ideal for events.

beginner

How do you configure a SharedFlow to replay the last event for new subscribers?

You set the replay parameter when creating the SharedFlow. For example, MutableSharedFlow(replay = 1) will replay the last emitted event to new subscribers.

beginner

What does it mean that SharedFlow is a hot flow?

A hot flow means it emits values regardless of whether there are active collectors. Events are produced continuously and shared with all subscribers.

beginner

How can you emit an event using a MutableSharedFlow?

You call the emit() suspend function or tryEmit() function on the MutableSharedFlow instance to send an event to all collectors.

What parameter controls how many past events a SharedFlow replays to new subscribers?

A capacity

B bufferSize

C replay

D cacheSize

The 'replay' parameter defines how many past events are replayed to new subscribers.

Which of these is true about SharedFlow?

A It is a cold flow that starts emitting only when collected

B It is a hot flow that emits events regardless of collectors

C It holds a current state like StateFlow

D It cannot have multiple subscribers

SharedFlow is a hot flow, meaning it emits events regardless of active collectors.

Which function is used to send an event to a MutableSharedFlow?

A emit()

B collect()

C subscribe()

D launch()

The emit() suspend function is used to send events to a MutableSharedFlow.

Why is SharedFlow preferred over StateFlow for one-time events?

A SharedFlow holds the latest state

B StateFlow replays all past events

C StateFlow is not observable

D SharedFlow can replay a limited number of events without holding state

SharedFlow can replay a limited number of events and does not hold a current state, making it better for one-time events.

What happens if you collect a SharedFlow after some events have already been emitted and replay is set to 0?

A You receive no past events, only new ones

B You receive all past events

C You receive only the latest event

D The flow throws an error

With replay set to 0, new collectors receive only new events emitted after they start collecting.

Explain how SharedFlow works for event handling in Android Kotlin apps.

Think about how events are shared and replayed to subscribers.

Describe the difference between SharedFlow and StateFlow and when to use each.

Consider how each flow handles data and events.

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