Lifecycle Management
The SDK manages most of its own lifecycle automatically: it starts a background worker on init, batches events, sends them periodically, persists anything that can't be delivered, and resumes when the device comes back online. For the vast majority of integrations you do not need to think about lifecycle at all. The two methods documented in this section exist for the cases where you do — when a critical event must be sent immediately, or when you want to tear the SDK down cleanly at sign-out.
Manual Flush
Under normal operation, the SDK groups events into batches and ships them on a schedule controlled by batchSize and flushIntervalSeconds. For most events this delay is invisible, but some moments require immediate delivery — a completed purchase, a user signing out, an app about to be backgrounded. In those cases, call flush() to force the SDK to send everything in the queue right now.
Because flush() returns a Future, you can await it to be sure the data has left the device before proceeding with the next step (for example, navigating to a confirmation screen or signing the user out).
B2Metric.instance.logEvent('purchase_completed', properties: {'order_id': 'ord_789'});
await B2Metric.instance.flush();
Shutdown
Calling destroy() releases all resources held by the SDK: it stops the background worker, closes the persistent queue, and disposes of any pending timers. After destroy() returns, the SDK is no longer initialized and cannot accept events until you call init() again. Use this method when you want to reset the SDK with a different configuration, or when your application is shutting down in a controlled way (for example, in a test teardown).
await B2Metric.instance.destroy();
Automatic Session Management
A session is a continuous period of user activity inside your application. Sessions help you measure engagement: how often users return, how long they stay, what they do between launches. The SDK manages sessions for you completely — it watches the app lifecycle (foreground, background, termination) and the inactivity timer, and emits three reserved events at the right moments:
first_open— fires exactly once, the very first time the application is launched after installationsession_start— fires at the beginning of each new sessionsession_end— fires when the session ends — either because the user has been inactive longer than the configured timeout, or because the application is terminating
The inactivity period that determines the end of a session is controlled by the sessionTimeoutMinutes config field (default: 30 minutes). If the user backgrounds the app and returns within the timeout window, the original session continues; if they return after the timeout has elapsed, a new session starts. You don't need to call any of this manually — these events appear in your B2Metric project automatically as soon as the SDK is initialized.
Session events are reserved — do not log them yourself with logEvent(). Doing so would duplicate the automatic events and corrupt your session-based metrics in the dashboard.