Question

My app uses region monitoring when it is backgrounded. As soon as the app enters the background I take their location (which I already have in the foreground) and create a region around it and start monitoring that region.

I'm using cocoa lumberjack for logging, and inside of applicationDidFinishLaunchingWithOptions I set up the logging and once I do I log "Starting logging...". Typically I expect to see this only when the app first opens up, or if for some reason the app crashes and I have to relaunch it and look at the logs to determine why. Doing testing today driving around I noticed 15 instances of "Starting logging" in my file over the course of 5 hours, always a few minutes after I create a region, like this (I removed out location specific info):

  • 7:17pm: CREATED REGION: regionFor: [xxx, -xxx] with radius: 200
  • 7:25pm: Starting logging....

(Here I do a couple of quick location updates to see if they move and send a request to a server, which takes about 1 second then create another region to monitor...)

  • 7:25pm: CREATED REGION: regionFor: [xxx, -xxx] with radius: 200
  • 7:44pm: Starting logging....

(Here I do a couple of quick location updates to see if they move and send a request to a server, which takes about 1 second then create another region to monitor...)

  • 7:44pm: CREATED REGION: regionFor: [42.77846, -71.42591] with radius: 100
  • 8:04pm: Starting logging....

There are logs in between I removed related to location updates and the server request that I don't think are relevant... I'm just wondering why the heck applicationDidFinishLaunching is called at those points as I only ever see it called when the app is starting for the first time after it was forcible terminated by the user, the phone itself was restarted, or the app crashed, as opposed to being awakened from the background which is what I expect from region monitoring from what I've read. Is this expected behavior or is my app crashing and then somehow being started again by the OS?

One thing to note is I will likely be moving towards starting a background task to process the location updates and send the request as I'm sure there are times where the location updates might take a bit and the request might take a while as well so I need more than the ~10 seconds I've read you get to process the didExitRegion update, but that seems irrelevant to this seemingly odd behavior I've seeing. Any help would be greatly appreciated.

Was it helpful?

Solution

This is expected and normal behavior. By setting region monitoring, you are not keeping the app alive in the background. The OS will still decide when and if to sleep or kill your app in the background. Your monitored regions persist and your app will be awakened when appropriate.

If your app is killed or asleep, you will see application:willFinishLaunchingWithOptions: and application:didFinishLaunchingWithOptions: methods of the app delegate called. You can check the options keys to tell if your app has been awakened by a location event.

From the app delegate class reference:

UIApplicationLaunchOptionsLocationKey The presence of this key indicates that the app was launched in response to an incoming location event. The value of this key is an NSNumber object containing a Boolean value. You should use the presence of this key as a signal to create a CLLocationManager object and start location services again. Location data is delivered only to the location manager delegate and not using this key.

For the most part, if your locationManager is created in this method, you will not do anything differently. Depending on your use case, you may handle the delegate call differently when in background or you may just react same in all states. That is something you will have to consider for yourself.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top