Ves al contingut principal

Flutter Integration

Recommended patterns for integrating the Eixam SDK into your Flutter host app.

For the shortest end-to-end sequence, start with Recommended Integration Path.

Create one SDK instance during app bootstrap and inject it into your app state or dependency container:

class AppBootstrapper {
  Future<EixamConnectSdk> createSdk({
    required EixamSession session,
    required EixamNotificationTexts notificationTexts,
  }) {
    return EixamConnectSdk.bootstrap(
      EixamBootstrapConfig(
        appId: session.appId,
        environment: EixamEnvironment.sandbox,
        notificationTexts: notificationTexts,
        initialSession: session,
      ),
    );
  }
}

Thin host-app rule​

Keep your host app thin. The SDK owns the core safety and runtime logic — your app owns UX and navigation.

Your host app should:

  • Own UX and navigation
  • Request permissions intentionally
  • Subscribe to SDK streams
  • Call SDK methods

Your host app should not:

  • Recreate backend operational logic already owned by the SDK
  • Parse BLE protocol directly in widgets
  • Hardcode transport or topic logic

Session refresh​

When a user logs in or out, update the session explicitly:

await sdk.setSession(
  const EixamSession.signed(
    appId: 'partner-app',
    externalUserId: 'partner-user-123',
    userHash: 'signed-session-hash-rotated',
  ),
);

await sdk.refreshCanonicalIdentity();

Lifecycle recommendations​

  • Bootstrap once per app start
  • Keep one live SDK instance — do not rebuild it for ordinary UX events
  • Update the session explicitly when login or logout changes the identity
  • Create SDK streams once and reuse them; do not call watch...() from rebuilding widgets when the result is used as an app-shell dependency
  • Let OTA and regional configuration finish reconnect/verification before starting another reboot-causing device action

App-shell integrations​

Some SDK events can arrive outside a specific feature screen. Subscribe near the authenticated app shell for:

  • watchSosCapability() and sosLifecycleStream when global SOS entry points depend on readiness.
  • watchNotificationIntents() when notifications can route anywhere in the app.
  • watchDeviceCountryConfigStatus() when a newly connected device may require user-confirmed regional configuration.

For regional configuration, prefer DeviceCountryConfigModalHost from eixam_connect_ui; see LoRa Radio Region.