Reconnection
FlushKit automatically manages the SSE connection lifecycle based on your app's state.
Connection lifecycle
App launched → SSE connects
App backgrounded → SSE disconnects (saves battery)
App resumed → SSE reconnects
App closed → SSE disconnects
Exponential backoff
When a connection drops unexpectedly (network loss, server restart), the SDK reconnects automatically using exponential backoff:
| Attempt | Delay |
|---|---|
| 1 | 2 s |
| 2 | 4 s |
| 3 | 8 s |
| 4 | 16 s |
| 5+ | 30 s (cap) |
The SDK only reconnects when the app is in the foreground. No reconnection attempts are made while the app is backgrounded or closed.
What happens to missed notifications?
If a notification is sent while the SSE connection is closed (app backgrounded or closed), it is queued on the server and replayed automatically when the app reconnects. No notifications are lost.
If your use case requires delivery to offline or closed apps, consider pairing FlushKit with FCM/APNs push notifications. Background delivery via FCM/APNs is on the FlushKit roadmap.
AppLifecycleState integration
The SDK listens to Flutter's AppLifecycleState automatically:
// This is handled internally by FlushbarRemote — you do not need
// to implement this yourself.
@override
void didChangeAppLifecycleState(AppLifecycleState state) {
switch (state) {
case AppLifecycleState.resumed:
_connect(); // reconnect
break;
case AppLifecycleState.paused:
_disconnect(); // save battery
break;
default:
break;
}
}
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
},
);
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.