search

Estimote / react-native-proximity

React Native wrapper for Estimote Proximity SDK
Apache License 2.0
61 stars 38 forks source link

onEnter Not Fired After Quick Refresh #11

Open gchallen opened 6 years ago

gchallen commented 6 years ago

I'm observing the following confusing behavior when iterating on an app we're developing. If I start the app after a few minutes, I see a nearby beacon immediately on load. (Good!) However, if I then reload the app (just the JavaScript) quickly I never see the nearby beacon immediately on load. (Bad.)

Note that, strangely enough, this also seems to be the case when I reinstall the app using react-native run-android. About half the time I see something immediately on startup, and half not.

I'm suspecting that there is some caching or timeout being used by the underlying Estimote SDK or somewhere else. Which is fine, I guess—although it would be nice if it were customizable for development purposes. But if enter events are going to be delivered there needs to be a way to get at the underlying estimate of whatever zone the library thinks that it's in...

heypiotr commented 6 years ago

iOS or Android?

gchallen commented 6 years ago

Sorry: just Android for now. Broken on a Google Pixel XL running Android 8.1.0. Working on a iPhone SE running iOS 14.11.1.

heypiotr commented 6 years ago

Gotcha, thanks for sharing. Probably a cleanup issue or something like that, I'll take a look!

gchallen commented 6 years ago

Thanks! Happy to help if I can.

heypiotr commented 6 years ago

I tested this scenario, and I think I might know what's going on. Android 6 or 7 introduced limits for how frequently an app can start BLE scanning => the limit is 5 start-scans per 30 seconds. I started the app, scanning started just fine, then I quickly reloaded it, and indeed, I saw these messages in logcat:

08-03 12:16:10.781 27058 27070 E BtGatt.GattService: App 'com.example' is scanning too frequently
08-03 12:16:10.782 26931 26999 D BluetoothLeScanner: onScannerRegistered() - status=6 scannerId=-1 mScannerId=0

@gchallen, maybe you can verify if you also see this, so we can be sure we've discovered the same problem here.

The native Android Proximity SDK actually starts quite a few scanners (I counted 10) under-the-hood, since we currently implement a simple "each type of packet/frame we need to detect gets its own scanner" logic. Hence it bumps into the 5-per-30-seconds limit immediately on the second attempt to start the Proximity Observer.

Not sure what a good resolution would be for this right now. Re-architecting the Android Proximity SDK to use be more efficient and use less scanners is probably a good goal, albeit a long-term one.

For the short-term, I'm thinking just some kind of warning/error. Unfortunately the native onError didn't trigger for me in this case, so we'll need to change that in the native SDK as well. (Or I can figure out if I can somehow track that directly in this RN plugin, but that seems to me like an inefficient and clunky "fix", so I'd rather work with our native SDK engineers on this.)

gchallen commented 6 years ago

Thanks for the update. I do suspect that this is the issue and can try to confirm at some point later.

When this happens, does the SDK eventually recover and start detecting beacons again? Or is it blacklisted forever? Obviously the latter is a more serious failure modality...

Having a warning or error generated would be great, and a way to disable and then reenable the underlying SDK to work around the problem.

heypiotr commented 6 years ago

AFAIK, this is an error that prevents Bluetooth scanning from starting, so it won't recover automatically. You need to wait and start the scan again. This could be automated in the SDK though, I guess.

gchallen commented 6 years ago

OK great. What actually triggers the start of scanning? I'm assuming it's the call to startObservingZones? I can build some logic into the app to ensure that that's not called too quickly.

heypiotr commented 6 years ago

Yup, startObservingZones is is.

gchallen commented 6 years ago

What's a safe interval?

And does this also happen if startObservingZones is called after the app is started, for example after a configuration change?

heypiotr commented 6 years ago

What's a safe interval?

Not going into too much detail, it's 1 startObservingZones per 30 seconds.

And does this also happen if startObservingZones is called after the app is started, for example after a configuration change?

Not sure exactly what you mean. This problem generally happens when there's a second call to startObservingZones within less than 30 seconds of the first one. So this could also happen if e.g. you start observing in reaction to some user action, and the user triggers that action twice or more within 30 seconds.