Question 1

What is the difference between a Future and a Stream?

Accepted Answer

In one sentence: a Future is one value, a Stream is a sequence of values arriving over time. The analogy helps a lot: Future is the async counterpart of T, Stream the async counterpart of Iterable. Then list the practical differences: Completion: a Future completes once and never changes. A Stream emits as many events as it likes until done, and can even continue after an error. Consumption: you await a Future; you read a Stream with listen or await for. Cancellation: a Future cannot be cancelled; a Stream subscription can, with cancel() — an important architectural difference. If an operation must be cancellable, model it as a Stream. Backpressure: a Stream has pause()/resume(); a Future has no such concept. Say when you pick each: a one-off result (an HTTP GET, reading a file) → Future; a continuous source (WebSocket, sensor, a DB watch(), user input) → Stream. Add a closing line: any Future can be turned into a stream with Stream.fromFuture, and the reverse works via first, last or toList — so conversion is easy, only the semantics differ.

Question 2

What is the difference between single-subscription and broadcast streams, and when do you pick each?

Accepted Answer

Give three differences in order — answering only "the number of listeners" is half an answer. 1. Listener count. A single-subscription stream accepts one listener for its whole life; a second listen throws a StateError. A broadcast stream accepts any number. 2. Buffering. A single-subscription stream holds events until listen — nothing is lost. A broadcast stream holds nothing: only whoever is listening at the moment of add receives it, and a late subscriber never sees earlier events. 3. Backpressure. With a single-subscription stream, pause() can genuinely slow the source (an async* generator suspends, a file read waits). With a broadcast stream the source does not pause — events are just buffered for that listener. How to choose: default to single-subscription, because buffering and backpressure make it safer. Use broadcast only when the source is a broadcast by nature: auth state, connectivity, an event bus, user events. Add one practical warning: if a public repository API returns a Stream that several places may listen to, returning a single-subscription stream leads to a surprise StateError. Either return a broadcast stream, or create a fresh stream on every call — the second option is often cleaner, since each consumer gets its own source and cancellation stays simple.

Question 3

How do you manage stream subscriptions so that you do not leak memory?

Accepted Answer

Start from the principle: listen is an obligation and cancel is how you pay it. An uncancelled subscription keeps the callback and its whole captured object graph alive, tries to write into disposed state, and leaves the source (socket, timer, platform channel) open. Then describe the concrete practice: I hold the subscription in a field: StreamSubscription? _sub; and await _sub?.cancel(); in the object's dispose()/close(). With several subscriptions I collect them in a List> and cancel them all in dispose — that makes it hard to forget one when adding another. Where possible I prefer constructs that cancel automatically, such as await for or StreamBuilder — the most reliable cancellation is the one you never had to write. If I create a StreamController, I close() it in the same place — the owner of a controller is responsible for closing it. I enable the cancel_subscriptions and close_sinks lints in analysis_options.yaml; that is more reliable than code review. Say a word about detection too: when I suspect a leak, I check in the DevTools memory view whether the instance count of an object grows every time a screen is opened and closed — the classic signature of a leaked subscription.

Question 4

Where are streams used in real applications? Give examples.

Accepted Answer

Answer by category — it sounds far more organised than a flat list: User input: a search field (with debounce, so not every keystroke fires a request), scroll position, form validation. Network: WebSockets and Server-Sent Events, chunked downloads of a large file — the http package's StreamedResponse works exactly this way and is what makes progress reporting possible. Platform events: location updates, the accelerometer, battery status, connectivity changes, incoming push notifications. Databases: Firestore snapshots(), Drift/Isar watch() — a new event arrives as soon as the query result changes and the UI updates itself. That is a push model instead of a pull model. Internal event bus: auth state changes (a logout must be felt on every screen), locale and theme changes. Then add a design observation, which makes the answer memorable: most of these should be broadcast because several places listen, while network and file reads should be single-subscription because backpressure matters there. Choosing the stream type is an architectural decision, not a technical detail. If you can give an example from your own work, do: which stream, which problem, and where you cancelled it.

Question 5

How do you use a StreamController correctly, and who owns it?

Accepted Answer

Start with the ownership principle: whoever creates the controller is responsible for closing it. It sounds obvious, but unclear ownership is the main cause of leaks in real projects. The correct usage pattern: Keep the controller in a private field: final _controller = StreamController.broadcast(); Expose only the Stream: Stream get orders => _controller.stream; — exposing the sink breaks encapsulation, because any code can then push events. await _controller.close(); in dispose()/close(). Check isClosed before add — adding to a closed controller throws a StateError, and that happens very easily after an async gap. Then ask and answer a more important question, which is a senior signal: do you actually need a StreamController at all? Often not: If the stream is just a transformation of another stream — map/where/asyncMap is enough. If the stream is generated — an async* generator is cleaner and handles cancellation for you. A StreamController is really for adapting imperative sources (callback APIs, platform events, a manual event bus) into a stream. Finish by mentioning the onListen/onCancel callbacks: they let you start the source only when someone is listening and stop it when the last listener leaves — a real saving in battery and data, and very few candidates know about them.

Property	Single-subscription (default)	Broadcast
Number of listeners	One, ever; a second `listen` throws a `StateError`	As many as you like, at any time
Events emitted before `listen`	Buffered — the listener receives all of them	Lost — a late subscriber never sees them
Pause behaviour	The source pauses or buffers (backpressure works)	The source does not pause — events are buffered for that listener
Typical source	File reads, an HTTP response body, an `async*` generator	User events, an event bus, timers
How to create one	`StreamController<T>()`	`StreamController<T>.broadcast()` or `stream.asBroadcastStream()`

Stream basics

📚 Sources and documentation