Design Pattern: Always Connected
Always Connected apps need to constantly stay connected to the device.
Keep up-to-date readings and diagnostics by remaining connected, whether the app is in use or backgrounded/killed.
Example: Sports/Health Tracking
Sports-tech devices typically are used for periods of time where data is sent to the app constantly. In these cases, the app needs to collect, perhaps process, store, and display information in real-time. Even if the app is not being used, the data stream should continue and no data be lost.
On the device side:
First, the fitness device should make it easy for the phone to find it. Emit an advertisement on a quick interval for the phone to detect. While this could be the standard BLE advertisement it already uses, there is a standard proximity advertisement (iBeacon) that should be used. This will save power on the device and also allow the app to use less power while searching.
Second, the device can also encourage the mobile OS to stay connected by sending a regular heartbeat, status, or other data periodically via indications or notifications.
On the phone side:
The phone needs to be actively scanning for the device's BLE advertisements. Since scanning constantly is a power drain, the app would use scanning APIs optimized for power and efficiency.
Worth noting: iOS has built-in optimized scanning for iBeacon advertisements that will notify apps (even backgrounded/killed ones) and let you connect and interact with a device.
Once connected, apps will maintain the connections while in the foreground. Once the phone is locked, or the user switches apps, then the Bluetooth connectivity starts to slow, eventually disconnecting.
Worth noting: A reliable way to prevent a mobile BLE connection from disconnecting in the background is to listen for periodic notifications from the device.
If the device emits a notification/indication periodically, make sure to listen for the data.
When disconnects occur (e.g the user went out of the device range), the phone needs to attempt a reconnection.
Worth noting: On iOS, this is easy because calling connect will queue up a connection request. This remains open until the device comes back in range.
On Android, the connection request has to be made manually every 5s (Android 10+) or 20s (Android <10), otherwise the connection request will timeout.