Explain single-subscription vs broadcast Streams in Dart

WHAT THIS TESTS: Whether you understand the fundamental contract differences in the dart:async library between single-subscription and broadcast streams, specifically around listener cardinality, lifecycle timing, and event buffering behavior. Interviewers want to see that you know why Flutter uses broadcast streams for UI events like button taps and single-subscription streams for async computations like HTTP responses.

A GOOD ANSWER COVERS: First, define that a single-subscription stream allows exactly one listener over its entire lifetime and begins emitting events only after someone listens; if you call listen twice it throws a StateError. Second, define a broadcast stream as one that supports multiple concurrent listeners but does not buffer or replay events, meaning a listener that joins late simply misses whatever was already emitted. Third, give a concrete use case for each type, such as a single-subscription stream for a file download or network request where the data is consumed once, and a broadcast stream for a global event bus or user input stream where many widgets need to react simultaneously. Fourth, mention that you can convert between them using the asBroadcastStream method on a single-subscription stream, though that changes buffering guarantees.

COMMON WRONG ANSWERS: Saying that single-subscription streams can have multiple listeners if you just wait for the first to finish; they cannot, the contract is enforced by the runtime. Claiming that broadcast streams automatically replay history to new subscribers; they do not unless you explicitly build replay behavior on top. Asserting that both stream types buffer all events indefinitely; in reality single-subscription streams may buffer briefly before the first listen but broadcast streams drop events for late listeners. Also, confusing StreamBuilder behavior with stream type, since StreamBuilder manages its own subscription but the underlying stream rules still apply.

LIKELY FOLLOW-UPS: How would you share a single HTTP response stream across multiple widgets without recreating the request? The expected answer is to use asBroadcastStream or a state management solution. What happens to events emitted before any listener attaches to a single-subscription stream? The answer is they are typically buffered by the stream controller until the first listen occurs. When should you avoid broadcast streams? When event ordering and backpressure matter, because broadcast streams do not pause the source for slow listeners. How do you handle memory leaks with streams in Flutter? You should cancel subscriptions in dispose and consider using listen callbacks carefully.

ONE CONCRETE EXAMPLE: Imagine a Flutter app fetching user profile data. You create a single-subscription stream from an HTTP client; only one listener consumes the bytes, and attempting a second listen crashes. Conversely, a ThemeChangeNotifier exposing a broadcast stream lets both the app bar and a settings page listen at the same time; if the settings page navigates away and returns later, it will not see the previous theme event because broadcast streams do not replay.