I’m adding beacon monitoring to an existing app that already uses CoreLocation for GPS positioning. The Estimote SDK is version 3.2.5. All sample code in the SDK works perfectly. However in the app it seems that sometimes things get tangled up due to the existing GPS code setting the delegate for CoreLocation. The app does not need to monitor the GPS location, only get the current location. Is there a way to have both CoreLocation functions or is it either/or?
Can you let us know in what way things gets tangled up?
CLBeaconRegion is a subclass of CLRegion, and regions are a systemwide resource, so if you start monitoring for beacons, you’ll be getting results delivered to your CL delegates as well as the EST delegates. If that’s the case, then you can simply filter them out by class (CLBeaconRegion vs CLRegion) in your CL delegate.
Digging deeper into the legacy code, it appears that my delegate gets replaced by the legacy delegate in some cases. I can deal with that by filtering on class, as you suggested. A bigger problem was having two separate keys in the project plist file:
NSLocationAlwaysUsageDescription, added by me
NSLocationWhenInUseUsageDescription, already in the project plist
This was actually preventing me from getting notifications while region monitoring.
Yup, your app will only ask for Location Services once, the very first time it calls either requestWhenInUseAuthorization or requestAlwaysAuthorization. Which means that if you use/have both, and “when in use” triggers first, you won’t be able to do monitoring. So, either ask for “always” permission exclusively, or—if you want to give the user a choice—you can easily detect which level of permission the app currently has via the didChangeAuthorizationStatus delegate and prompt the user to go to Settings and switch the authorization level to “always”.