Using iBeacons to trigger synchronization with external piece of hardware
There are many overviews of what can be done using iBeacons. Our friends from Mutual Mobile published a comprehensive summary on what you can and can’t do. We’d like to share some a non-typical way of using Bluetooth Low Energy (BLE) on iOS.
We’ve recently been working on an app for a fitness tracking service, which included communication with a BLE device. One of the requirements for this app was to connect to the device every few minutes to trigger notifications for users. Everyone who tried to make an iOS app do anything at a scheduled interval, while the app is in background, knows how hard this task is.
Our first try was to use notifications from
CBCentralManagerDelegate, which are delivered when a device is discovered. It seemed obvious to solve the problem this way, as the device was advertising all the time, so the notifications should also arrive on time. Unfortunately, it failed miserably. While the app was in the foreground this solution worked pretty well, but in the background the app stopped receiving notifications after a few minutes which seemed to be a result of how iOS preserved battery life.
Next, we tried to keep the connection with the device open and register for changes on one of the BLE characteristics in
CBPeripheral. This worked a bit better, we received more notifications than in the previous solution, but it was still far from perfect. Also, it turned out that it drained the activity tracker battery overnight.
iBeacons to the rescue
Focusing on the pure Bluetooth LE API failed. We started thinking what we could do to get better results combined with energy efficiency. During one of the meetings someone proposed to use the iBeacons API and modify the tracker so it sends an iBeacons advertisement every time it had a new bunch of data. We gave it a shot and it worked amazingly well.
The integration went smoothly. We only needed to register to proper region in
CLLocationManager and add suitable background modes for communicating with external hardware. That went really quickly, so we could start testing. It turned out that over the weekend we got over 99% of notifications delivered to the app. It was what we were looking for. Using iBeacons had another advantage. When an app gets killed by the OS, whenever a new advertisment is received, the app gets restarted. The new solution reduced the phone battery consumption significantly.
The app was developed not only for iOS. On Android, however, this wasn’t an issue. Apps can schedule regular background tasks which can be used to synchronize with the tracker.
We got everything working, but we still had one test to pass. The iBeacons technology was introduced for location purposes and the location permission popup appeared when app started monitoring for iBeacons. As this is still quite a new technology and our solution was unprecedented, we were curious how Apple would handle it. The app was approved, although it took some time as we had to ship an actual device to Cupertino for a full review.
Many people think about iBeacons as a location-based technology. Normally the iBeacons are broadcasted by a passive piece of hardware, which is placed somewhere to notify about its proximity. We can extend that thinking by using them in a variety of devices to communicate with apps in background, even when the phone is in standby mode. Have you heared about any other not-trival usage of the iBeacon technology? Leave your comment below.
Lead Software Engineer