Location update after suspending the app from background

[sobri909]

Location update after suspending the app from background

[sobri909]

Unfortunately not. iOS doesn't provide location data while apps are suspended.

If you only need low accuracy, infrequent location updates, and want to allow your app to suspend, you can use iOS's "significant location changes".

Otherwise your best option is to use ArcKit's "Sleep Mode" feature (which is on by default anyway). Sleep Mode allows for continuous, all day location recording, with minimal battery use.

[kalyan711987kalyan]

I have installed ARC app and suspended the app. But still I was able to see you were tracking user location. How you made it possible?

[sobri909]

Arc App never actually suspends. It's always running in the background, 24/7.

Arc App keeps battery use low by using ArcKit's sleep mode while stationary. By using that, battery use can be kept to the absolute minimum when the user isn't moving between places, so the device should still make it through whole days on a single charge.

[kalyan711987kalyan]

Sorry, I made you confused.
I killed Arc app from background. But still able to see location tracking.
How can I implement similar feature on my app?

I created APIkey and integrated ARCkit through pods. I 'm not able to get timelineitems?
Can you help ?

[sobri909]

Ah ok. Arc App is getting relaunched after termination because it's monitoring "significant location changes".

https://developer.apple.com/documentation/corelocation/cllocationmanager/1423531-startmonitoringsignificantlocati

If an app is monitoring significant location changes and it is terminated by the user, then eventually iOS will relaunch the app, once the user's location changes enough.

From Apple's docs:

If you start this service and your app is subsequently terminated, the system automatically relaunches the app into the background if a new event arrives.
...
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.

So that means that if the user terminates the app, it may get relaunched automatically once the user has moved 500+ metres. Arc App is monitoring significant location changes as a safety net, to make sure the app is properly relaunched in those cases.

I created APIkey and integrated ARCkit through pods. I 'm not able to get timelineitems?
Can you help ?

If you're wanting TimelineItems then you'll need to use the latest beta of ArcKit (TimelineManager is still in beta, although it's very close to final release).

pod 'ArcKit', '>= 5.0.0.pre'

[kalyan711987kalyan]

I have integrated ARC SDK and it is working fine. But I noticed battery consumption is more.
We are uploading Smooth Data to our Server to share with other app user also, so some how we can see that SDK is generating too many data, so is there any way we can reduce number of data based on Distance, Time Duration when Device is moving ?

[freeubi]

Of course, you can.
Just implement a point reduction algorithm, and run it before you send the data up to your server.
For this purpose, I'm using this framework:
https://github.com/malcommac/SwiftSimplify
With this, I can get the same drawing with much less point to draw and save :)

[sobri909]

If you are using TimelineManager (or PersistentTimelineManager) you can also reduce the location update frequency with the samplesPerMinute setting:

https://github.com/sobri909/ArcKit/blob/master/ArcKit/Base/Timelines/TimelineManager.swift#L40-L45

[sobri909]

For battery consumption, it's most often other things that are consuming more energy, for example UI updates, map views, and sending data to/from servers.

The location recording itself is optimised to be as energy efficient as is physically possible. So you're likely to get more energy savings by being more careful about UI / map updates, and how much data you send and receive over the internet.

Try turning off major subsystems, and turning off the entire UI, and doing battery testing like that. Then enable them each one by one, to find which ones are consuming the most energy.

For example, in Arc App, even though it's recording 24/7, the main energy consumers are the map view and the daily iCloud backups.

[sobri909]

You can however get more energy savings out of LocomotionManager by carefully adjusting various settings.

maximumDesiredLocationAccuracy: Try to avoid setting this value lower than 30. Typically, accuracy doesn't improve below that value, but energy consumption does increase. So unless you require the app to attempt absolute best accuracy, without regard for energy consumption, you should avoid setting this lower than 30.

dynamicallyAdjustDesiredAccuracy: Make sure this is set to true (the default value).

If you don't require motion data, make sure you turn off recordPedometerEvents, recordAccelerometerEvents, and recordCoreMotionActivityTypeEvents.

useLowPowerSleepModeWhileStationary: If you're recording location data for hours rather than minutes, make sure you've got this option turned on.

sleepAfterStationaryDuration: This goes with the above setting. Try to avoid setting this higher than a few minutes. The default value of 3 minutes is suitable for most cases.

sleepCycleDuration: If you're doing all-day recording, it's worth testing different settings for this value. Higher values will conserve more battery, but will result in slower wake ups when the user starts moving after stationary periods.

[sobri909]

Oh, one more potential energy saver: If you're using TimelineManager / PersistentTimelineManager and don't require activity type classification (ie you don't need to know whether samples/paths are walking/running/car/etc), then disabling activityTypeClassifySamples will avoid wasting energy on activity type classification.