Design Pattern: Proximity Aware
Proximity Aware apps need to perform an action automatically when nearby a device Responding to a nearby device is useful when you want to automate certain features of your app. Let's talk about what needs to be done in the app and device to make this happen.
Proximity Aware apps need to perform an action automatically when nearby a device
Responding to a nearby device is useful when you want to automate certain features of your app.
Example: Smart Lock
The app currently unlocks a door when the user taps a button. In order to make a more seamless experience, you'd like the app to detect the door and initiate the unlock process.
Apps detect the presence of devices using their BLE advertisements.
On the device side: the lock device needs to emit an advertisement 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.
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.
On iOS, this is built directly into the operating system via CoreLocation.
Android does not provide any beacon detection out of the box. For that reason, a lot of teams use AltBeacon to build energy-efficient iBeacon detection into their Android apps.
The app can automatically detect when (and how close) it is to the device using these APIs.
Note about distance estimations: Estimating the distance to a Bluetooth device is more precise when the phone and device are closer to each other. Distance calculations are less reliable past 2m. While this is out of scope here, here is some great info about how Bluetooth signals can be used to detect distance from an app.
Impacts
Advertising: if the app needs to connect to the device, then the iBeacon advertisement will have to be alternated with a 'normal' connectable advertisement.
Power: iBeacon advertisements are meant to be power efficient if following Apple's guidelines. There may be a small energy cost in switching advertisements on the device. On the phone, BLE scanning always comes at a power cost, but CoreLocation works to keep this minimal on iOS. On Android, you will have to experiment with the timing in AltBeacon.
Questions, or something not clear?
Let me know below!