stopRanging does not seem to stop actual ranging

[BobOtike]

Hello,

I'm setting up a project where as soon as the app is started, monitoring begins. I want to have the reactions of the app to be rather fast, so I set the background scan period to 3000/100 ms. As certain events occur, ranging will be launched on top of the monitoring and is stopped after another event occurs.

As my understanding goes, monitoring would give its results every 3.1 s at first, then when ranging is started the result will be delivered every 1 s and after deactivating ranging again, the scan period for beacons goes back to the monitoring frequency of 3.1 s.

To emulate this behaviour without having too many outer influences, I have set up the following: In my activity is one button, that when pressed instantiates the beaconManager, connects and starts the monitoring. A second button then lets me start and stop the ranging. Upon clicking the first button again, the beaconManager will be disconnected. I have run this app and collected the following log.

03-13 16:13:54.403 I/OpenGLRenderer: Initialized EGL, version 1.4 03-13 16:13:54.423 D/OpenGLRenderer: Enabling debug mode 0 03-13 16:13:54.623 I/Timeline: Timeline: Activity_idle id: android.os.BinderProxy@37e6d5d5 time:410662263 03-13 16:13:57.656 D/ViewRootImpl: ViewPostImeInputStage ACTION_DOWN 03-13 16:13:57.866 I/EstimoteSDK: com.estimote.sdk.service.BeaconService.onCreate:277 Creating service 03-13 16:13:57.896 D/MainActivity: Connected to BeaconService 03-13 16:13:57.896 D/Adding client: android.os.Messenger@59a39d 03-13 16:13:57.896 D/EstimoteSDK: com.estimote.sdk.service.BeaconService$IncomingHandler$1.run:707 Setting background scan period: ScanPeriodData{scanPeriodMillis=3000, waitTimeMillis=100} 03-13 16:13:57.996 D/BluetoothLeScanner: onClientRegistered() - status=0 clientIf=6 03-13 16:13:58.046 D/BluetoothLeScanner: onClientRegistered() - status=0 clientIf=6 03-13 16:13:58.116 D/BluetoothLeScanner: onClientRegistered() - status=0 clientIf=6 03-13 16:14:01.219 D/BluetoothLeScanner: onClientRegistered() - status=0 clientIf=6 03-13 16:14:04.403 D/BluetoothLeScanner: onClientRegistered() - status=0 clientIf=6 03-13 16:14:05.344 D/ViewRootImpl: ViewPostImeInputStage ACTION_DOWN 03-13 16:14:05.434 D/Ranging: started 03-13 16:14:05.524 D/BluetoothLeScanner: onClientRegistered() - status=0 clientIf=6 03-13 16:14:07.396 D/Ranging: Listener executed 03-13 16:14:07.456 D/BluetoothLeScanner: onClientRegistered() - status=0 clientIf=6 03-13 16:14:08.497 D/Ranging: Listener executed 03-13 16:14:08.567 D/BluetoothLeScanner: onClientRegistered() - status=0 clientIf=6 03-13 16:14:09.578 D/Ranging: Listener executed 03-13 16:14:09.628 D/BluetoothLeScanner: onClientRegistered() - status=0 clientIf=6 03-13 16:14:10.629 D/Ranging: Listener executed 03-13 16:14:10.679 D/BluetoothLeScanner: onClientRegistered() - status=0 clientIf=6 03-13 16:14:11.760 D/Ranging: Listener executed 03-13 16:14:11.810 D/BluetoothLeScanner: onClientRegistered() - status=0 clientIf=6 03-13 16:14:12.851 D/Ranging: Listener executed 03-13 16:14:12.901 D/BluetoothLeScanner: onClientRegistered() - status=0 clientIf=6 03-13 16:14:13.892 D/Ranging: Listener executed 03-13 16:14:13.942 D/BluetoothLeScanner: onClientRegistered() - status=0 clientIf=6 03-13 16:14:14.292 D/ViewRootImpl: ViewPostImeInputStage ACTION_DOWN 03-13 16:14:14.372 D/Ranging: stopped 03-13 16:14:15.113 D/BluetoothLeScanner: onClientRegistered() - status=0 clientIf=6 03-13 16:14:16.234 D/BluetoothLeScanner: onClientRegistered() - status=0 clientIf=6 03-13 16:14:17.285 D/BluetoothLeScanner: onClientRegistered() - status=0 clientIf=6 03-13 16:14:18.366 D/BluetoothLeScanner: onClientRegistered() - status=0 clientIf=6 03-13 16:14:19.457 D/BluetoothLeScanner: onClientRegistered() - status=0 clientIf=6 03-13 16:14:20.538 D/BluetoothLeScanner: onClientRegistered() - status=0 clientIf=6 03-13 16:14:21.569 D/ViewRootImpl: ViewPostImeInputStage ACTION_DOWN 03-13 16:14:21.679 D/Removing client: android.os.Messenger@59a39d 03-13 16:14:21.679 D/BluetoothLeScanner: onClientRegistered() - status=0 clientIf=6 03-13 16:14:21.689 I/EstimoteSDK: com.estimote.sdk.service.BeaconService.onDestroy:350 Service destroyed

The "onClientRegistered" seems to me as the indication of one concluded scan period. At first they occur at a frequency of approx. 3 s, which is the monitoring. After starting the ranging, the frequency is increased to once per second, which is also fine. I've placed a log output inside the ranging listener to confirm its being executed. After stopping the ranging it seems only the ranging listener is suppressed from being executed, but the "onClientRegistered" calls continue every second.

This leads me to believe, that ranging is not actually stopped but only the listener is being removed. This would mean my app is constantly ranging after it was once started, which is not very desirable. I can't seem to find the reason why ranging is not being stopped properly. Or am I misinterpreting something here?

[BobOtike]

I have tried the following workaround:

I stop all the monitoring before commencing the ranging and after finishing restart the monitoring. Now the period of 3.1 s is restored properly. There seems to be some correlation that starting ranging while monitoring influences the monitoring frequency as well.

This approach would normally be fine, but it gives me another problem. All the regions I have been in when starting the ranging are "forgotten" when restarting. That means, after finishing the ranging, the onExitedRegion will not be called for all the regions I was previously in if I have left them during the ranging. This is also not very desirable for my use case, because rely on the enter and exit events to take some actions in my app.

[pawelDylag]

Hello @BobOtike !

At first, It's always nice to know a little bit more about your SDK version and your phone - scan deeply depends on Android version, and in that way we can easier find code that is working with your version.

As to your problem with ranging - we're investigating that, and as far as I'm concerned, it is in fact a bug within our SDK. Fix is on the way and shall be released in next sdk version soon (probably at the end of this week). Thank you very much for discovering this problem :)

If I may suggest you a temporary workaround referring to your second post:

I stop all the monitoring before commencing the ranging and after finishing restart the monitoring.

Try not to stop monitoring before starting ranging. Instead, stop it after finishing ranging, and then start it back again as usual - it will update scan period to proper one for monitoring. It's hacky, I know, but we'll fix that :)

Have a nice day and let me know if that helps!

[pawelDylag]

Ok, quick update: don't stop your monitoring. Just start it once again after you finish ranging :)

[BobOtike]

Thank you @pawelDylag for you fast response.

Of course, totally forgot about that: I'm running Android 5.0.1 on a Galaxy S4 and use v0.10.0 of the SDK.

I have tried your latest advice with not quite the right result. The scan period for monitoring will be reinstated but the new problem is, that for every time I start the monitoring, another execution of the onXXXRegion callbacks is added. That means, after I have ranged the first time and started the monitoring anew, the next time I enter a region the onEnteredRegion will be executed twice. The same applies for onExitedRegion. After the next ranging, I get three calls to the monitoring listener functions and so on.

[pawelDylag]

The problem is with updating scan period - after exiting from ranging state, scanner keeps ranging period for monitoring. We fixed that today and it should be OK in the next SDK version. As for now, you can try juggling with starting/stopping monitoring. You're right about onXXXRegion callback, I omitted that. Last thing that comes to my head is doing as I previously said -> stop monitoring and start it again after ranging. Otherwise - you need to wait until next release (later this week) :)

[BobOtike]

Thank you for taking care of this issue, I will just wait for the new SDK since the wrong scan period is not a crucial matter for my use.

My point in the last comment was only to state that this behavior seems not intuitive to me. If I already monitor a region and start monitoring the same region again, be it on purpose or accidentally, I would neither want nor expect for the listener to be called more often.

I have noticed the same behavior for the ranging as well. If you start ranging a region more than once, you even get a log that the region is already being ranged and that this would be ok. With this log and also the statement in your SDK reference that

If given region is already ranged, this is no-op.

I would not expect that anything changes because of another start.

[pawelDylag]

Any update, @BobOtike? We fixed that issue in version 0.10.1 - could you confirm, that your ranging is ok now? Can I close this issue?

[BobOtike]

Yes, I got the new version and this issue seems to be solved now. Thank you very much.