Nearables Wearables: Connecting Beacons with Smartwatches for Indoor Positioning

Android

Using the same system on the phone and the watch allows using all existing libraries, animations and SDK features on a small screen, so we were expecting to use Estimote SDK on the watch the same way we would on a phone. With the recent Android Wear update’s Wi-Fi support (if it is available on the hardware level), we wanted to use wireless connection to send data from the sticker to the server.

iOS

We have already seen nearables monitoring work on iOS when testing Estimote SDK. What we really wanted to find out was if standalone Apple Watch apps could detect Estimote beacons, since watchOS 2 allows access to watch hardware and communicating directly with remembered Wi-Fi hotspots.

How it actually worked

Android

Fortunately, we had no problems with running Estimote SDK on an Android Wear smartwatch. Guys from Estimote prepared exhaustive examples (just don’t forget to add required permissions), so It didn’t take much time to write a simple service for the smartwatch to communicate with nearables in the background.

We did face some problems, though. For example, we couldn’t rely on the SDK to handle events when the device appeared in or fell out of the range of a nearable. It worked with beacons but not stickers. We just didn’t receive events from stickers. As a workaround, we had to use another option: the listener, that handles every event received from a nearable (about 2 sets of events from all stickers per second). And voilà - we managed to receive data from stickers. Now it’s time to share them with the server.

Previously, to send data from the watch to the server, we would use one of DataLayerAPIs to pass data to the phone, and then the phone would send it to the server. But with Wi-Fi on the watch on, can data be sent directly to the server? The answer is yes. But, of course, there are some details you should be aware of:

• The smartwatch should be disconnected from the phone.
• The smartwatch should be connected to a Wi-Fi network.

*Also, keep in mind that Wi-Fi can be automatically disabled when the battery is low (this can be configured in the watch’s settings).

Following these statements, you can use your regular code to send HTTP requests. In our case, we used the OkHttp library. We received data from the server to display locations of other people the same way. One of downsides here is that you can’t debug your app while your watch is disconnected from your phone. Basically, this is how it worked on my table with nearables, wear, phone on it.

watchOS

When monitoring the area to locate nearables, the existing Estimote WatchKit SDK works only for watchOS 1. The applications run on the iPhone and the Apple Watch is used here only to display the notifications. As far as for OS2 the applications run on the watch directly, we could not use this SDK here. We also tried different workarounds to make Apple Watch detect nearables, but it seems like Apple worked hard to prohibit this feature for the Watch.

The Geeky Part
We found that the native iBeacon SDK CoreLocation works with watchOS 2, and were excited to see if it could detect beacons. Unfortunately, all monitoring APIs are marked with the __WATCHOS_PROHIBITED attributes and are not available for watchOS2. This was shortly mentioned by Apple’s engineer during CoreLocation session at WWDC15, meaning that the smartwatch cannot monitor beacons the same way iOS does, especially in the background.

Another option to detect nearby beacons was to use CoreBluetooth and scan for peripherals when the app is in the foreground. This framework is hidden by default for Apple Watch but it can be added to the watch app extension. We saw that CBCentralManager is not visible in headers but exists in the runtime, so we tried to call scan for peripherals can find beacons on the iOS. Unfortunately none of the CBCentralManagerDelegate methods is called on Apple Watch.

We came up with several theories to explain why Apple decided to disable monitoring on the Watch:

• Not to consume smartwatch’s energy with monitoring.
• Not to allow third party apps to perform sync or notifying operations when the app remains in background and the watch is locked.
• As monitoring activities can be carried out on iOS, actual cases when users’ Apple Watch is only connected to Wi-Fi, without being paired with an iPhone can be very rare.

iOS

We wrote a simple demo app to search for the “known” nearables and send location updates to the server. Background mode had to be allowed for the app to perform background monitoring: “App communicates using CoreBluethooth”

There are 2 APIs that allow searching nearby beacons on iOS using Estimote SDK:

• Ranging. Triggered only when the device finds a nearby beacon. Run approximately 2 times per second if the user stays near a beacon.
• Monitoring. Triggered when a user enters or leaves the beacon region.

There are two options available while working with the APIs:

• to scan the environment, looking for all the beacons available within the area of reach;
• to search only for the beacons that have specific identifiers;

While both these options work great when the app is in the foreground, they behave differently when the phone is locked:

• Ranging. Doesn’t work when the app runs in the background. This was done not to launch application in background very often when user stays near beacon.
• Monitoring. Works only if you subscribe to receiving notifications about entering or leaving the area of beacons with known identifiers. This means that we can’t receive notifications about all the beacons found when the app runs in the background.

And one more thing. If the application was terminated by the user, the system will not launch it even if a monitored beacon was found. By killing the app, users sort of say they don’t want this app to perform any operations, so it’s quite logical that it doesn’t launch on its own. But if the application was killed by the system (e.g. because of memory pressure), iOS will launch and notify the app about the found beacon.