Beacon monitoring in background iOS

Question

I am developing an iOS app in Swift that monitors for beacon events. This is my first real beacon endeavor.

I am using Estimote beacons, but am not using the Estimote SDK. I am using core location and a CLLocationManager with didExit and didEnter events.

I am only listening for beacons that are registered with the current user that is signed in to my app. For example, John Doe could be registered with beacons A and B, while Mary Sue is only registered to beacon C. I am experiencing a lot of false leaves, and wonder if it is because of where I am implementing my code.

I understand that there is a default 30 second latency when validating a leave event, but I am experiencing periods of longer than 30 seconds without a bluetooth signal from point blank range. Perhaps implement a 30 minute window rather than 30 seconds for a leave validation?

Since a user has to sign-in in order to know what beacons to monitor, the location manager resides within the user's default profile view controller. I successfully get beacon interaction even when the phone is locked, but it is not consistent. I am concerned because I know that the view controller itself is suspended/activated at the iPhone's discretion and may be revealing flaws in my logic.

Should all location oriented code be placed within the app delegate file? If I implement a protocol from my profile view to the app delegate, I can instantiate it there within the app delegate first and then retrieve the beacon data later, once the user is signed in.

I have struggled to find an "iOS beacon convention" in my research, just examples that provide some results. Not too sure whats actually considered proper practice.

Thanks!

Answer 1

It is common to use a software filter to ignore spurious region exit events if an entry event happens soon afterward.

To make this independent of any one ViewController, it is important to have the logic triggered by the AppDelegate. Two choices here:

• Put region monitoring callbacks and filter logic directly in the AppDelegate. This is appropriate for small and simple apps.

• Put callbacks and filter logic in a custom class, and initialize it from the AppDelegate's didFinishLaunching method. This is the best approach for larger and more complex apps to keep the AppDelegate simple and clean.

Either way, it is critical to trigger starting of monitoring from the didFinishLaunching method. This ensures proper background CoreLocation setup should your app be auto launched by region transitions.