4

We want to incorporate beacon technology in our apps to create user engagement with screen-off events.

In the present use case, we assume that the end-user will be in constant movement.

So far, we have tested two different approaches.

  • Kontakt SDK/Android Beacon Library in order to be constantly scanning for beacons. Using the UUID (assuming we are using Eddystone), we can associate it with a cached message that we have retrieved for our back-end. However this ends up eating a lot of battery.
  • Nearby Messages/Nearby Awareness this had potential, since it has a beacon dashboard to easily configure the attachments on each beacon and it has the "same" implementation on both iOS and Android. However, after reading the documentation and after numerous tests, we could not retrieve beacon attachments if we had the screen off. The only possible way was for the user to be still in front of the beacon for 3 minutes (depending on the smart-phone and energy settings) and it goes against our premise that the user is in constant movement, so the scan might be triggered when the user is not near the beacon.

Also: using Nearby Messages on iOS we had the desired behaviour: the app would discover the beacons when using the Nearby Messages if both the app and the API was configured for background usage.

Thus, we ask:

  • Is there a way to use Nearby API with screen-off events? Like constantly scheduling a scan?
  • What other alternatives do we have, that can be used cross-platform between iOS and Android? (so that we can try to assure a similar behaviour between platforms)

EDIT: Upon further reading, we came to the conclusion that BLE beacon scanning causes minimal impact on the battery when used correctly (emphasis on the correctly, we will have to change the heuristics on our side), see : this. The question then remains: why can't we have background scans in the nearby api without Nearby Messages own notifications, so that we can assert that the user passed near a beacon? What intrigued us is that this works just fine on iOS...

Vanethos
  • 691
  • 1
  • 8
  • 20

1 Answers1

2

The Nearby API scans on a schedule of its choosing, including screen on events. You do not have the flexibility of customizing Nearby scanning rules for your app, as it is designed to be a service that runs for all apps on the phone. When using Nearby, you must accept this limitation.

The Android Beacon Library is open source and allows flexible configurations of when you scan. If you find your configuration uses too much battery for your use case you can adjust this. The default settings have been designed for a good tradeoff between power usage and quick detection, so these are recommended. If you find the default settings don't work for you there are many different ways you can set it up. The simplest way is by adjusting its scanPeriod and betweenScanPeriod for the background. But there are many other ways to customize its scanning behavior.

You should note, however, that a "constantly scheduling a scan" (as mentioned in your question) will use up a lot of power if in low latency mode. The Android Beacon library default is to do a constant scan in low power mode, when the app is in the background and no beacons are around. On most devices, this yields detections within 5 seconds and reasonable power usage similar to cell standby.

It's hard to offer more suggestions without knowing the configuration you used with the Android Beacon Library, the test conditions in place, and how much power consumption was witnessed. If you can provide this information, I might be able to help more.

Full disclosure: I am the lead developer on the Android Beacon Library open source project.

davidgyoung
  • 63,876
  • 14
  • 121
  • 204
  • 1
    First I have to thank you for your quick reply. Fiddling with the settings on the Android Beacon Library might be a good way to solve the problem, however we loose the benefits of the Google Beacon Dashboard. In iOS we had the results that we wanted, and so we have to ask: how come that an API that is created by Google has a better behaviour on iOS? It has to be scheduling some sort of task on the background when the screen is off, so why isn't the same behavior available on Google's own platform, Android? Lastly, is it possible to use Google Beacon Dashboard in parallel with your library? – Vanethos Dec 06 '17 at 16:40
  • I am actually very surprised to hear that you see better results on iOS -- in my experience it is much worse. Google has no special access to iOS APIs, so the Nearby SDK must rely on CoreBluetooth scanning just like the rest of us. And on CoreBluetooth, detecting service advertisements is generally slow in the background for service advertisements like Eddystone. It can take a minute or more, so users in motion often miss an advertisement as they pass by. It would be more likely to get better results on iOS if using iBeacon, as their platform and CoreLocation API is optimized for iBeacon. – davidgyoung Dec 06 '17 at 20:03
  • 1
    @davigyoung unfortunately I'm having the same issues reported by Vanethos. Since Google can't control iOS it has to use CoreBluetooth instead of screen-on events which, in my opinion are awful for user engagement. Let me explain my use case: I've 10xbeacons (Eddystone) in a straight 100m path, distancing 10m from each others. With both phones in my pocket, I walk/run through them and in the end, when I turn the iPhone on I've 10 checkpoints (success rate of 90%). When I turn the Android on I have only 1 beacon detected, the last one. Unfortunately in this use case, iPhone wins. – GuilhE Dec 07 '17 at 10:48