Estimote ranging in foreground become slow (more than 4s)

BLE Beacons
1

Hello ,
Recently we face couple of problems with Estimote android sdk ranging in foreground.

SDK tested :
com.estimote:sdk:1.0.15. and we update to the com.estimote:sdk:1.3.0.

Code of ranging :

   private void setupBeacons(Context context) {


    UUID uuid = UUID.fromString(mApplicationUUID);

    mAllBeacons = new BeaconRegion("regionId", uuid, null, null);
    mBeaconManager = new BeaconManager(context);
    mBeaconManager.connect(() -> onServiceReady());
    mBeaconManager.setRangingListener(new BeaconManager.BeaconRangingListener() {
        @Override
        public void onBeaconsDiscovered(BeaconRegion beaconRegion, List<Beacon> beacons) {
            processBeaconListenerResponse(beacons);
        }
    });
}

public void onServiceReady() {
    try {
        mBeaconManager.startRanging(mAllBeacons);
    } catch (Exception e) {
        e.printStackTrace();
    }
}

Problem :

  • Estimote ranging in foreground become slow in some new devices and we are getting result each 4 s or more.

Tested Device :

One Plus 5 7.1.1 Slow (updates every 4 seconds or so)
Nexus 5X 8.0.0 Slow (updates every 4 seconds or so)

Samsung A5 7.0 Works correctly, gets beacon readings every second
Samsung Galaxy S5 6.0.1 Works correctly, gets beacon readings every second

HTC One 5.0.2 Works correctly, gets beacon readings every second
HTC One M8 6.0 Works correctly, gets beacon readings every second

2

Hello!

We improved our scanning mechanism for 5.0+ Android devices in ProximitySDK alpha release. You can check it out here. It provides the same (but more reliable) experience as using iBeacon regions, but it’s based on top of our own protocol (EstimoteLocation). If your beacons support EstimoteLocation advertising, then I strongly recommend considering moving to this solution, because we are constantly working on it at the moment.

We are moving our Android stack to a new architecture, and you can track the changes in this topic →

Any feedback much appreciated!

3

I’m sure we are the same as many other developers in that we have to try and keep our code hardware agnostic. Our Situate platform supports any iBeacons (we recommend Estimote of course!), but sometimes we are working with an existing beacon infrastructure. So there is no way we can lock our platform into a particular manufacturer, however much we’d like to. Therefore we have to continue to use the Android SDK.

Have you seen similar results to those described in the question? We have seen that beacon scanning on all of our test devices that are running Android 7.1 or later is more than 4 times slower than when we were using Android 6. This makes the apps much less responsive and gives a poor user experience, especially when compared to iOS devices.

4

It is impossible to deliver the most reliable experience using generic iBeacon protocol and generic hardware. For the past couple of years we’ve been developing this technology and all our effort is put into the ProximitySDK now. In addition, as it comes to Android, we did a complete overhaul and totally improved scanning mechanism to match not only the plain Android OS, but also different device models - we put a lot of data-science in it. The architecture is so different, that it’s too difficult for us to fit it into our old (current) SDK. We decided to develop the new stuff under the hood of ProximitySDK leaving the old SDK behind.

:computer: From an engineering point of view, let me suggest you a possible solution:

  1. Hide beacon-interaction layer behind an interface.
  2. First, create old Estimote SDK implementation that works on iBeacon.
  3. Second, create implementation using our new ProximitySDK.
  4. If your client insists on using non-Estimote hardware, then tell them, that it won’t be as much reliable. Maybe show them a demo with ProximitySDK to let them see the difference. If they will still want to use it, just simply use the iBeacon-compatible implementation in their App.
  5. If they decide to go full Estimote - cool! Use ProximitySDK implementation that will provide the most reliable experience :slight_smile:

Btw. I’ve seen your Situate platform - it looks totally cool! Great job! :thumbsup:

Oh - and I am sure, that the problem you are having (with slow scanning on some devices) would no longer be the case in our ProximitySDK.