Reconnection
The SDK handles dropped SSE connections automatically using exponential backoff. You do not need to write any reconnection logic yourself.
Backoff schedule
| Attempt | Delay |
|---|---|
| 1 | 2 s |
| 2 | 4 s |
| 3 | 8 s |
| 4 | 16 s |
| 5+ | 30 s |
The delay doubles on each failed attempt until it reaches the 30-second cap, where it stays until a connection is established.
App lifecycle integration
The SDK registers a WidgetsBindingObserver during init and reacts to app lifecycle transitions:
| Lifecycle state | SDK behaviour |
|---|---|
AppLifecycleState.resumed | Opens (or re-opens) the SSE connection |
AppLifecycleState.paused | Closes the SSE connection |
AppLifecycleState.inactive | No change |
AppLifecycleState.detached | No change |
This means the SDK never holds an active connection while the app is in the background, which avoids unnecessary battery drain and data usage.
What happens while paused
Notifications sent while the app is paused are queued on the server and delivered as soon as the app resumes (Starter plan and above). On the Free plan, events sent while a device is offline are not replayed.
Observing connection errors
Connection errors surface on the events stream's onError handler:
FlushbarRemote.events.stream.listen(
(event) { /* ... */ },
onError: (error) {
debugPrint('Connection error: $error');
// The SDK will retry automatically — no action needed
},
);
The error callback is informational. The SDK will schedule a retry regardless of whether you attach an error handler.
Manual reconnect
There is no public API to force a reconnect. If you need to swap the API key at runtime (e.g. after a user logs in), call dispose followed by a new init call:
FlushbarRemote.dispose();
FlushbarRemote.init(
apiKey: newApiKey,
context: context,
);
The backoff timer is reset whenever the app transitions to resumed, so returning from the background always triggers an immediate reconnect attempt — not a delayed one.