Define the complete connection lifecycle
Start by documenting every state the product can enter: never paired, discovered, connecting, connected, temporarily disconnected, reconnecting and deliberately unpaired. The application should have one clear response for each state.
Treat the device state and the application state as separate sources of truth. A phone can believe it is connected while the peripheral has restarted, changed mode or invalidated a session.
- What state is shown to the user?
- Which commands are allowed in that state?
- What event moves the product to the next state?
Test the interruptions users actually create
A stable laboratory connection hides many release blockers. Repeat the workflow after Bluetooth is toggled, the device leaves range, the phone locks, the application is backgrounded and the peripheral loses power.
Each interruption should end in a predictable state. Automatic reconnection must be bounded, observable and easy for the user to stop when the device is no longer available.
- Peripheral power cycle
- Phone Bluetooth off and on
- Application background and process restart
- Out-of-range disconnect
- Firmware or protocol version change
Restore product state, not only the radio link
A successful reconnect is incomplete if the application does not restore subscriptions, refresh device status or reconcile commands issued before the disconnect. Recovery should rebuild the product session in a known order.
Log the connection reason, elapsed time, retry count and final state. These records make intermittent failures reproducible and give the handover team evidence instead of assumptions.
