This afternoon I walked my iPhone 4 into the Apple Store to see if they could help with a problem I've been having. Battery life hasn't been AT ALL what it should be--the battery drops 50% sitting on my desk overnight. Crazy. So I suspect I've got a bum unit. Happens. No biggie.
My friendly genius pokes around my phone a bit, and points out that the Location Services pointer is lit in the top right corner of the screen. He gets into the location services settings. He notes that the following apps have the "got location data in the last few hours" flag lit: The Weather Channel, Showtimes, and two apps I wrote and am days away from submitting.
He turns off the sliders for each of those apps, and we see the top corner location services pointer turn off. Turning back on location services for EITHER of my apps makes it turn back on, and that's NOT the case for Weather Channel or Showtimes. But it's clear that turning on location services for my two apps fires up the device's location services. My lousy battery life is explained, but that's just the beginning of the mystery.
Here's the thing.... Neither of my apps are EVEN RUNNING at the time. They're not even backgrounded. They're OFF. I think they're both built in a debugging profile on my device at the moment, and they both do use Core Location. They're not suspended, they're just flat not running. And yet, turning on the slider in the location services control panel for either of them fires up location services in general.
So... What the heck is happening here? Neither of those apps are configured for background location. And... they're not IN the background! And since I've had location services turned off for them, there's no doubt my battery usage is way way down.
The solution is at this thread in the Apple developer forum: https://devforums.apple.com/thread/58063?tstart=0
An earlier version of both of these apps had called [locationManager startMonitoringSignificantLocationChanges], and never called stopMonitoring.... Even though the current version of the apps didn't make that call, the OS still had the monitoring request "registered" to the apps (and was, in fact, relaunching them in the background as I drove around town!).
What I didn't know was that the monitoring request persists across launches--and across re-builds! I'd assumed that, like -startUpdatingLocation, the monitoring request would die with the process, but not so. The solution was to delete the apps from my device and reinstall.
Related
I am wondering if you know of a way in which n App can receive a messages/file or even "wakeup" while it is not active initially.
Please let me know if there is a mechanism or even if there is a path worth exploring.
It's not a mechanism and I never tested it but according to Apples Developer Library if your App is monitoring some area (up to 20 geofencing areas per App) and if you will enter that area, the Application will be relaunched, at least AppDelegate will be called even if the app is terminated.
If a region boundary crossing occurs while your iOS app is not
running, the system automatically wakes it up (or relaunches it) in
the background so that it can process the event.
Read here. Maybe this could help you a little. I'd love to see your finding on that topic. :)
I have some fancy idea about this. You could update the geofencing areas each time you will enter one. So you will have an App that will relaunch it self over an over if you have good network connection and are mowing around. :D
I have a CLLocationManager contained in a singleton and I have added around a dozen regions to monitor. I am successfully notified of boundary crossings when the app is in the foreground/background. However, when I force quit the app, the location icon disappears and I am not getting any callbacks.
As far as I can see, this is intended functionality as of iOS7. Here is a reply I found to a similar question, in this case involving significant location change: https://devforums.apple.com/message/882691#882691:
If a user swipes up in the app switcher then the OS will not launch the app unless explicitly told to do so by the user. So no, SLC will not be launching the app, nor will silent notifications. The only thing that will launch the app at that point is the user tapping the icon. The intention here is that the user has expressed their choice of not having that app running any more for any reason, so we honor that.
In this situation, there's really nothing that you can do. The next time the user launches the app you can let them know that some of the data may be missing, although you really cannot tell whether there's missing data or not (i.e. you might have been killed by the OS in the background and the user may not have moved thereby not triggering any SLC notifications). My suggestion would be to gather the data you can within the policies of the OS and if the user has manually killed the app then respect that wish and don't do anything.
By all means, feel free to file a bug report if this change in behavior winds up causing problems for you or (especially) confusion for your users.
I developed an application that uses "Location Significant Change" feature. I notice that after users download my app, they quickly tend to uninstall it because they see the white GPS icon on their iPhone, and they think it will drain their phone battery.
I wonder if there is any workaround or suggestion, I wonder also if Apple is going to do anything about the GPS icon when using "Location Significant Change" feature, either on iOS 6 or next versions.
on comparison Android have a feature where you could setup Alarm manager to wake up application on certain time intervals. This will solve the problem, is there something similar on iOS (or iOS 6 maybe).
Thanks.
This is going to be a non-negotiable aspect to using location services on an iOS device. Apple wants to inform users when their location is being used so they can make informed decisions. So overriding or hiding this location icon, is not going to happen. (jailbreak excluded)
In my opinion, you have a couple options to help yourself out.
Inform the users in your app description in the app store so they know up front that the battery life isn't going to be slammed that bad.
Have a good detailed message set when you ask for permission to use the user's location. This will let them know why and make sure they accept and allow it.
If you have an FAQ on your website or inside the app, make sure you detail what the icon means and reassure the user that Apple takes battery life very seriously, and so do you.
Outside that, there isn't a lot you can do. Just inform your users best you can and go from there. Good luck.
UPDATE
I found a setting in iOS 6 under Privacy-->Location Services-->System Services all the way at the bottom, there is a user setting to hide the stats bar icon. This frees up some status bar real estate for users that don't want to see it. It doesn't mean the app isn't using location, just the icon is hidden. This is something your users would have to do as overriding this is not an option. At least it is something to share with your users.
Note that the location arrow when using significant location changes is different from the one when you are actively using location services in the background. The best thing you can do is to make sure the user understand how is their location being used, and to teach them to identify the difference between location monitoring (like geofence and significant location changes) and location tracking.
My app registers for background location updates (not Significant Change. I need more granularity than kilometers)
That part works fine. I just want to stop the updates after the app has been in the background for 60 minutes. The way I'm doing it right now is to call stopUpdatingLocation in my CLLocationManager delegate.
However, I am unsure if this will actually stop my app from receiving background location updates, or if it will, but will just ignore them. Ideally, I'd like to not have my app be responsible for battery drain except for a small period of time after user activity.
Apple's documentation tends to send me in circles on this one. Right when I think "Executing Code in the Background" is about to spill the answer, it directs me to "Location Awareness Programming Guide." Right when that one is about to get specific about this question, it sends me back to "Executing Code in the Background." :)
I'm not sure whether your app has total control over this, but the docs for stopUpdatingLocation do state the following ...
Disabling event delivery gives the receiver the option of disabling the appropriate hardware (and thereby saving power) when no clients need location data
Which would suggest that should your app be the only one requesting background location data, and you request it to stop the GPS receiver would disable the appropriate hardware to save on power, which I think it was you're looking for.
What I can suggest is that you enable Power logging in Settings -> Developer, then run your app for an hour or so to a point where you think GPS is disabled, run for another hour and then compare the power usage in Instruments. This should provide you with a much clearer picture.
Calling stopUpdatingLocation will indeed stop GPS and so on, but if you place this call inside locationManager:didUpdateToLocation:fromLocation of your CLLocationManager delegate, then it might never be called.
Keep in mind that this method is only executed whenever a more accurate position or a (according to the active distance filter) significantly different position is available. If the device does not move at all and if the circumstances affecting the accuracy also do not change, it may not be called for hours (I have verified it for several minutes myself) and GPS will also stay enabled for this long.
For apps that only work in the foreground, you can use an NSTimer of 60minutes, but for apps that run in the background, the closest to a working solution that I have found so far, is a scheduled UILocalNotification. But even that requires the user to confirm an alert, before the app is restarted and able to turn the GPS off.
Maybe beginBackgroundTaskWithExpirationHandler: is the key to a better solution, but I have not completely figured it out, yet.
I have a requirement in my iPhone app that I know when somebody running the same app is close by.
I'm thinking that GameKit using Bluetooth would let me do that. GPS location is not precise enough in this particular case.
However, if the user closes the app then the function won't work anymore. Even under iOS4, the task switching will close down the BonJour services so I can't have the app run in the background.
Seems to me I can only have this function if the user leaves the app up and running. Would you agree? Or is there a different approach I can take?
People are very concerned with privacy, so they would naturally expect such privacy invading functionality to be switched off when they close down the application.
If they choose to have this feature enabled, then it's a different matter. Then they expect that somebody else may locate them.
You might however consider implementing some sort of opt-in offline service, where the latest gps position is stored on a server including a timestamp. When somebody else (with the app running) moves within a certain distance of this location while it's still "fresh", then you send off a notification to the first device. That way the user would be notified that somebody may be close, and can then switch on their own device.