I have a problem with rangingBeaconsDidFailForRegion delegate method. It is called for an infinite number of times and I’ve putted a breakpoint to see for what region is this happening and every time it’s a different region UUID, for regions I don’t even range for beacons.
I have to specify that I use EstimoteSDK 2.4 because I have Indoor Location in my app too.
I also have to specify that this is happening when I disable bluetooth from settings in my device.When I reenter in the app the issue begins.
I also have to specify that in centralManagerDidUpdateState delegate method I call the method stopRangingBeaconsInRegion, so the rangingBeaconsDidFailForRegion delegate method should not even get called at all.
Our SDKs simply forwards whatever “ranging did fail” message it gets from iOS, and iOS will keep calling this method as long as ranging is started and Bluetooth is disabled. Personally, I think the result is a lot of unnecessary “spam” (wouldn’t it be enough to get this message just once?), but when designing our SDK, we need to weigh “should we improve the iOS’s behavior” vs “should we keep it the way it is, so that people familiar with Core Location feel at home when migrating to Estimote SDK.”
Still, you shouldn’t be getting “did fail” messages for regions you’re not ranging … Can you post some example UUIDs that you don’t range for, but are still getting in the “did fail” delegate?
Thank you very much for the answer. I can give much more details now.
First of all, i am raging for 3 regions ,all of them have the basic Estimote UUID “B9407F30-F5F8-466E-AFF9-25556B57FE6D”, but each have different majors, minors and identifiers. Before I put the app in background and disable bluetooth from settings I have to specify that in my code I stop the ranging for all the 3 regions, so I believe that after ranging is stopped ,even if I disable bluetooth it shouldn’t be any kind of problem. But when I reenter in the app this rangingBeaconsDidFailForRegion method keeps being called continuously. I check the regions UUID as you suggested and I discover that every time is exactly the same sequence of UUID’s.
Here ar the first 5: 4E5A3705-ABC0-46EF-BA23-7BA0539F77EE
52DDA4F4-913F-4F62-A1CA-F3868020C87A
6AA2EE50-D6DC-4348-BA3E-C9BEB15B31E6
6B77DE6F-9932-4F45-A800-77F80E3C523C
701EB593-43BB-4158-AC1C-54D9A09133E0 and so on…
Thanks, I checked the SDK 2.4 and it looks like there’s a bug—regardless of whether you use Secure UUID or not, it’ll always range for secure beacons. The regions you’re seeing are related to secure ranging (as secure beacons rotate their UUIDs from time to time).
This bug doesn’t exist anymore in SDK 3.x, as starting with v3, we completely separated detecting secure and non-secure beacons. I know this doesn’t help you at this moment, since you need 2.4 to use Indoor Location. We’re almost there with updating Indoor SDK to use v3 though, it should be out in about two weeks, so this problem will soon go away. For now, the best temporary solution I can think of is to manually filter out any regions you know you’re not ranging for from the rangingBeaconsDidFail delegate … ):
Thank you very much.It’s not a big problem for me, because manual disabling the bluetooth from settings while using the app is not a common use case scenario and beside that all is working ok.I was just very curious why this is happening. Can you please when you can explain me how do the app know about these regions? I didn’t understand very well.