Behaviour for Significant Change Location API When Terminated/Suspended

Behaviour for significant change location API when terminated/suspended?

Since I asked this question, I have done a fair bit of testing (mostly on the train between home and work) and have confirmed that the behaviour for suspended apps is as I suspected at the end of the question.

That is, your suspended app is woken up, you don't receive any callbacks on your app delegate, instead you receive your location updates through your existing CLLocationManagerDelegate. You can detect that you are running in the background by checking the applicationState, and do limited work for the case where you are woken from a suspended state to do location processing.

[UIApplication sharedApplication].applicationState == UIApplicationStateBackground

I came to this conclusion with a location test harness that you are welcome to download and try out. It is a pretty simple app that allows you to turn on significant change and GPS change APIs through the UI and log all the responses that you get back.

N.B. Point six in the previous answer is not correct. Freeze dried suspended apps do receive CLLocationManagerDelegate callbacks when they are woken up from a suspended state.

iOS Significant Location Change Detection When Application Is Closed

you have to ask Always permission to run your app in the background. The app will awake if the significant location is changed even if your app is killed. By that time you can not change any UI component (i.e. change label text etc.) Other than that your code is correct.

How to handle SignificantLocation change when an iOS app is in suspended state?

When you say "...I need to call an API service..." are you talking about making a network call to a server? If so, then yes, you should ask for background time.

I seem to remember you only have about 30 seconds of background time, and network calls can take unpredictable amounts of time.

You want to make the call beginBackgroundTaskWithExpirationHandler, and then call endBackgroundTask once your server call is complete.

Update Location when app is terminated

In a word, no. You could subscribe to significant location change notifications. Then when the system detects that the user has moved by "a significant distance" (defined by the system.) I'm not sure what the system calls a significant location change, but it's going to be a lot more than 50 feet.

Another alternative would be to create a geofence around the user's current location and listen for location updates using the Core Location startMonitoring(for:) function.

Both of those techniques will relaunch your app if they detect a relevant event and your app isn't running.

iOS swift backgound location update when killed/suspended with minimum data loss

question-1

What is the difference between using startMonitoringSignificantLocationChanges Vs startUpdatingLocation?

startUpdatingLocation updates the location when it is called first time and then when the distance filter value exceeds.

it uses the GPS when its available, if you use in continuously it Drain your power/battery

Discussion

This method returns immediately. Calling this method causes the
location manager to obtain an initial location fix (which may take
several seconds) and notify your delegate by calling its
locationManager:didUpdateLocations: method. After that, the receiver generates update events primarily when the value in the distanceFilter property is exceeded. Updates may be delivered in other situations though. For example, the receiver may send another notification if the hardware gathers a more accurate location reading.

Calling this method several times in succession does not automatically
result in new events being generated. Calling stopUpdatingLocation in
between, however, does cause a new initial event to be sent the next
time you call this method.

If you start this service and your application is suspended, the
system stops the delivery of events until your application starts
running again (either in the foreground or background). If your
application is terminated, the delivery of new location events stops
altogether. Therefore, if your application needs to receive location
events while in the background, it must include the UIBackgroundModes
key (with the location value) in its Info.plist file.

In addition to your delegate object implementing the
locationManager:didUpdateLocations: method, it should also implement
the locationManager:didFailWithError: method to respond to potential
errors.

startMonitoringSignificantLocationChanges when a significant change in position occurs.

it uses cellular or wifi, when it work the location is changed or its called in the particular Time interval.

Discussion

This method initiates the delivery of location events asynchronously,
returning shortly after you call it. Location events are delivered to
your delegate’s locationManager:didUpdateLocations: method. The first
event to be delivered is usually the most recently cached location
event (if any) but may be a newer event in some circumstances.

Obtaining a current location fix may take several additional seconds,
so be sure to check the timestamps on the location events in your
delegate method.

After returning a current location fix, the receiver generates update
events only when a significant change in the user’s location is
detected. For example, it might generate a new event when the device
becomes associated with a different cell tower. It does not rely on
the value in the distanceFilter property to generate events. Calling
this method several times in succession does not automatically result
in new events being generated. Calling stopMonitoringSignificantLocationChanges in between, however, does
cause a new initial event to be sent the next time you call this
method.

If you start this service and your application is subsequently
terminated, the system automatically relaunches the application into
the background if a new event arrives. In such a case, the options
dictionary passed to the locationManager:didUpdateLocations: method of
your application delegate contains the key
UIApplicationLaunchOptionsLocationKey to indicate that your
application was launched because of a location event. Upon relaunch,
you must still configure a location manager object and call this
method to continue receiving location events. When you restart
location services, the current event is delivered to your delegate
immediately. In addition, the location property of your location
manager object is populated with the most recent location object even
before you start location services.

Note:

Apps can expect a notification as soon as the device moves 500
meters or more from its previous notification. It should not expect
notifications more frequently than once every five minutes. If the
device is able to retrieve data from the network, the location manager
is much more likely to deliver notifications in a timely manner.

for differenciate purpose I taken from here

question-2

If we use startUpdatingLocation does it impact on publishing the app to the App Store?

One of the possible reasons for 2.16 rejection is the absence of GPS battery warning in your app description on the app meta in iTunesConnect - "The continued use of GPS may decrease battery life" or something like that.

for More information related to this

Question-3

When the app is killed/suspended (Force closed by the user) it takes some time to restart the location manager from the AppDelegate which causes loss of location data for a period of time. Any possible solution to overcome this

NO, we Can't Over Come, reason the memory newly Initiated.

iOS Significant-Change Location event doesn't update the app every 15 mins

According to a reply by an Apple staff member to this thread on the Apple developer forums, there may be a discrepancy between the documentation and what you, the original poster on that thread, and I myself are observing (i.e. that in contrast to what’s documented, there may not be updates every 15 minutes).

Note the phrasing in the documentation: “every 15 minutes, at minimum”. We all seem to have interpreted that “minimum” as the minimum frequency (i.e. once per 15 minutes, or twice per 15 minutes, or more). But it could also be read as the minimum time interval (i.e. every 15 minutes, or every 30 minutes or more). It doesn’t give a guarantee of how frequent, but rather sets an expectation of how infrequent the updates will be. The documentation isn’t wrong, but certainly open to multiple interpretations.

What’s important is what the Apple staff member states in their reply:

[…] simply using [significant location change] does not guarantee that your app will be resumed as [sic] some periodic rate.

PS. For those who can do something about the documentation: rdar://30345408 (not mine)

---

Related Topics