I am developing an iOS (7.0+) application for fitness (running) that uses the users GPS location, does a small calculation and transmits the data to a Bluetooth Low Energy (4.0) watch. This process needs to be happening in the background, even when the user locks their iOS device.
I have implemented the following background modes as well:
App communicates using CoreBluetooth
App registers for location updates
I have successfully been able to get everything to work well, except for after a certain amount of time (ex. 2 hours) when the device is locked, the iOS device stops updating the location because I can see that it is no longer sending updating GPS values to the Bluetooth watch. I then have to unlock the device, re-open the app and location services works as it should again.
Does anybody know how to keep location services running the whole time in the background (device locked) without it suddenly stopping the location updates after a certain amount of time? If possible, an efficient solution would be preferred that does not drain the battery too much more than it normal would for using GPS.
Most important: make sure you are setting pausesLocationUpdatesAutomatically to NO before you start the CLLocationManager (see docs).
To minimize battery usage you should also use deferred location updates (more details on SO). This allows the CPU to sleep and save battery while the GPS chip collects location updates for you. It periodically dumps them to the CPU. This may not be for you if you need to update the watch once a second, but if you can update it every 10 or 20 or 30 seconds it will save that many CPU wake ups.
Related
We are in the process of developing Minder app for obVus (https://www.obvus.me/) which focuses on developing user-friendly products to change behavior and condition healthy habits.
Minder app (https://apps.apple.com/us/app/minder/id1437980397) allows you to check in with how you are feeling throughout the day. Minder tracks healthy posture stats, wear time, steps, mindful minutes, heart rate, goal, and Me/Mo progress which are all visualized on our intuitive, user-friendly dashboard. Minder syncs to Apple Health to keep all your vital health data in one place.
We are using Apple Watch and Airpods as wearable devices to track postures. We would like to incorporate Airpod posture tracking when Minder app goes to background!
Our team did research and we found that Air pods automatically get disconnected when we put the app to background by its default behaviour. We are automatically reconnecting it when we launch the minder app to foreground.
There are only limited number of background execution modes our app can support that enable it to run when in the background, such as playing audio, receiving location updates, or processing scheduled tasks etc. Here is the apple reference doc for the background services that our iPhone, iPad, Apple Watch, and Apple TV apps require to continue executing in the background: https://developer.apple.com/documentation/xcode/configuring-background-execution-modes
In the case of Apple Watch, this is possible since the minder app uses a workout session to track a user’s activity on Apple Watch but such mechanism is not available in AirPods
Can you please help us on this? Is there any mechanism to track user’s postures by using Aipods as sensors while the app goes on background . Can you please guide us so that we can incorporate Airpod posture tracking when our Minder app goes to background.
You can start a HKWorkoutSession to keep your Watch app to continue executing code in the BACKGROUND (For Watch)
Or start a Location Updating that allowBackgroundUpdate = true (For both Watch & Phone)
The biggest issue is High Power Consumption.
Here are some tips that you can apply to save battery for Watch/Phone.
When using HKWorkoutSession, start it and then pause it after 1 second to save battery.
When using CLLocationManager, start it after set distanceFilter = 3000, desiredAccuracy = 3000. It is like you just wanna run app in Background not updating location. With long distance filter and low accuracy, battery consumption rate will be very low.
Avoid running too many timer instances.
Limit the I/O usage
iOS: How to use location tracking during predefined time period while saving battery life?
I need to activate location tracking during predefined time periods (does not matter if app in background or foreground) and need to be sure that battery life is not impacted too much?
PS:
Please not that running location in background with tracking significant changes does not suits because it gives you location after 10 min and only when you passed reasonable amount of distance ... so during driving 40 km I got location only 3 times that will not allow me to catch user movement near some point. If running location more often ...that drains battery upto 40 percent per 6 hours...
I've researched all background modes in iOS very thoroughly recently.
The only deterministic way that will allow you to do that, without location background mode are silent pushes.
You send a silent push to the user and the user returns a location.
You could also use background fetch. But it's very non-deterministic. You can't predict if it indeed will wake up your app, or not.
EDIT:
Please note, that this will not wake up the app that was forcefully terminated.
However, the system does not automatically launch your app if the user
has force-quit it. In that situation, the user must relaunch your app
or restart the device before the system attempts to launch your app
automatically again.
Many questions concerning iOS Location tracking have been asked on here, but recently Apple has updated much of their functionality and so many of the answers are obsolete, my question is specifically targeting iOS 8 and 9.
I am interested in creating a location tracking application which will accurately track the user even when the app is closed. To do this, apple states:
If you leave the significant-change location service running and your
iOS app is subsequently suspended or terminated, the service
automatically wakes up your app when new location data arrives. At
wake-up time, the app is put into the background and you are given a
small amount of time (around 10 seconds) to manually restart location
services and process the location data.
So my understanding is, if you have all of the necesarry permission and plist keys present, the OS will wake up your app and allow you to do something for 10 seconds, or if it needs more time it can:
If an iOS app needs more time to process the location data, it can
request more background execution time using the
beginBackgroundTaskWithName:expirationHandler: method of the
UIApplication class.
Now, this says that if my app needs more time to process the location data, it may start a background task (with an expirationHandler) to handle that. When reading about background tasks, I read that background tasks can run for a maximum of 10 minutes
So my overall question is, when my app gets woken up when a significant location change has occurred, is it possible to start the standard location service and have it run in the background indefinitely? Is it possible to start another background task before the first one expires?
EDIT:
From the Apple Documentation it says:
because it wakes the system and your app at least every 15 minutes,
even if no location changes have occurred, and it runs continuously
until you stop it
So my idea is, if the user starts their phone from nothing and never opens the app, after at most 15 minutes (even if they are standing still), the OS will fire my app, in which case I could start a background process that I can start the GPS tracking in, and thus getting accurate GPS location. Would this logic work with the OS?
The main problem is that significant location changes cannot be used for
"accurately track" the user.
Significant means 1000m, since it is cell tower based, and not GPS based.
So your app is woke up when the user moves into the next GSM cell.
This is not acurate enough for acurate tracking.
finally this means you cannot acuratley track when the app is closed, this works only in running app or background running up.
"When reading about background tasks, I read that background tasks can
run for a maximum of 10 minutes"
No, thats not true. My app runs in background and records GPS locations until the battery is drained (8h+). (It does not use the significant location mode)
I'm currently working on an iOS app using objective-C that send every minute gps coordinates to my API.
I've used AFNetworking & CoreLocation, I also wanted my App to run all day long, but only send coordinates if time is between 8am - 6pm.
Everything's working fine on iOS simulator targetting iOS9 my app is sending his location every 1 minute to my API, even if i press home or lock the phone.
PhoneCall, loss of network or GPS have been handled in order to keep my task running.
But when I tested it on some device (iPhone 4S on iOS9) Location stop updating after an average time of 1hour to 1hour and a half.
Is iOS shutting down my app in background after a given time?
If so, is there a way to keep my app doing her job in background for at least 10 hour, without having to prompt the device user?
Implementing long running background task are "allowed" by apple if it concern:
"The app keeps users informed of their location, even while it is running in the background."
Does that mean background task will block my http request after a while?
For long term deployment, I wish my app to be upload on the App Store, but I've read many post about app GPS tracking app which have been rejected.
Here's the minimal list of requirement my app should have:
Send GPS coordinates to my API every minute
Working in background for a minimum time of 10 hours without shutting down or prompting user to reload the view
Could those requirement be accepted to get my app upload on AppStore?
Or will I have to use local/remote notification and prompt the user to reload my app in order to keep it running for such a long time?
The documentation says.
The significant-change location service is highly recommended for apps that do not need high-precision location data. With this service, location updates are generated only when the user’s location changes significantly; thus, it is ideal for social apps or apps that provide the user with noncritical, location-relevant information. If the app is suspended when an update occurs, the system wakes it up in the background to handle the update. If the app starts this service and is then terminated, the system relaunches the app automatically when a new location becomes available. This service is available in iOS 4 and later, and it is available only on devices that contain a cellular radio.
I think this will be apt for your scenario.
I would like to use region monitoring in iOS , for location based alerts/calculations.
I'm worried that it would drain the battery.
I searched for it on the iOS reference , and couldn't find any evidence for it.
Is that service available at all times , regardless of the region monitoring (i.e. scanned every minute or so...) or should I use the "significant location change" API instead ?
update : so , battery usage isn't dramatic. Its pretty good actually.
would like to receive some advice regarding switching between the modes (region/standard).
After checking for almost 2 weeks , I can tell that region monitoring does not significantly drain the battery.
As a matter of fact , it will be an active service in iOS 5 for sure , as the built-in reminders app will use region monitoring 24/7.
Region monitoring shouldn't have anywhere near the same affect on battery life as location tracking does.
According to Apple's developer documentation, region monitoring is built upon CoreLocation's "significant-change" location service. In order to conserve battery life, this service does not poll position information using aGPS, but instead simply tracks changes in the user's current cell tower.
Whenever the cell tower changes, iOS calculates whether any region boundaries were crossed. If a region crossing occurs while an iOS app is not running, iOS automatically wakes it up (or relaunches it) in the background so that it can process the event via the didEnterRegion:/didExitRegion: callbacks.