My iOS app uses location services in the background when in a certain mode of operation. It works fairly well, managing to stop processing if the user disables LocationServices in Settings/Privacy - either globally or for my app only - while it is in the background.
When the user disables location services for my app only, all goes fine. When the user disables location services globally, however, I'm not able to prevent the standard alert saying 'Turn on Location Services to Allow "MyApp" to Determine your Location' from appearing (I mean, the alert shows almost immediately while I am in the Settings app, not when I come back to my app resuming it to the foreground).
I seem to understand that other location-based apps are able to avoid this: for example, MotionX-GPS does not cause any alert to appear when recording a track in the background, even if the user disables global location services in Settings. Does anybody know how to achieve this?
Thanks,
Wolf
<CLLocationManagerDelegate>'s locationManager:didChangeAuthorizationStatus: looks promising. You could implement that method in your CLLocationManager delegate, and shut yourself down depending on the new CLAuthorizationStatus value.
Related
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'm using background geolocation to schedule local notifications when the user is in a specific location.
Since theses notifications are link to a commercial operation I've got a date, stored in the userdefaults to manage when I should disable the background geolocation when the operation is other.
I don't want the user to have to launch the application to be able to disable the significant changes monitoring.
So I tried to stopMonitoringSignificantLocationChanges the CLLocationManager directly in the locationManager:didUpdateToLocation:fromLocation: but it doesn't seam to work.
Any advice? What is the best practice for this issue?
Thanks.
Given the rules of the road for backgrounded applications or apps that aren't running, your hands are somewhat tied here.
Here is your one and only option if you want to disable location without any interaction from the user.
Each time your user's location updates from the background, your location manager delegate will receive this update. You don't get a lot of processing power here, so keep it short and sweet or register for a long running background task, check your date and if you are done with location, call the stop monitoring call there, reset any data or flags in your user defaults and you are done.
If you trigger from a local notification, the user will need to click on the open button to perform any actions. You can fire notifications from your background location delegate method for sure. But that is your one and only path to automating anything without user interaction. What you do there is up to you. There is no problem with checking for location udpates and turning that off from the background delegate method.
I am running my iPod touch application and then go in background and change the device language from Settings application and try to bring that application on foreground. My application gets restarted and I do not land on the screen where I left the application when I went into the background.
Is this because a KILL signal is sent by settings application when language was changed? Is it the desired behavior?
I wasn't aware the switching the language would cause apps to be terminated, but that's not shocking. It's a very straightforward way to get what the user wants. Your problem isn't the language change, though. The problem is that you're not responding correctly to a notification of termination. You can be terminated at any time when you're in the background, and it's your job to deal with it.
Your application delegate should implement applicationWillTerminate: (or you can observe UIApplicationWillTerminateNotification wherever it is convenient). When you receive this, you should save off sufficient information to get yourself back to where you were when you restart. As much as possible, you should make it look to the user that you did not terminate. The easiest place to save state is usually in NSUserDefaults, but you can use any mechanism you like.
Handling application restart is one of those things that separates excellent iOS applications from "good enough."
I want to stopMonitoringSignificantLocationChanges when the user is killing the app from the multitask bar (switch bar) like the Waze GPS App does.
(i also want to cancel all LocalNotifications)
the problem is, that after an application get's suspended, applicationWillTerminate doesn't get called.
The way Waze does it is by running the NORMAL LOCATION SERVICE in background, not the "significant location service".
a special option that can be set in the plist file.
there is no way to close the Low Power mode of location services - "Significant location service" when the user kills the app, because it was not intended to be used this way.
I guess I will simply have to follow apple's standards using significant location service.
did you have a look at this post: Behaviour for significant change location API when terminated/suspended?
Lots of interesting things in it.
In particular, you should stopMonitoringSignificantLocationChanges on entering background and register for significant location changes with a Service
What is the proper way of ending an application on the iPhone when you are finished with it?
thanks,
anton
Jaanus is referring to this paragraph in the Apple iPhone Human Interface Guidelines
Stopping
People quit an iPhone application by opening a different application. In particular, note that people don’t tap an application close button or choose Quit from a menu. In iOS 4.0 and later, and on certain devices, the quitting application moves to a suspended state in the background. All iPhone applications should:
Be prepared to quit at any time. Therefore, save user data as soon as possible and as often as reasonable.
Save the current state when stopping, at the finest level of detail possible. For example, if your application displays scrolling data, save the current scroll position.
iPhone applications should never quit programmatically because doing so looks like a crash to the user. There may be times, however, when external circumstances prevent your application from functioning as intended. The best way to handle this is to display an attractive screen that describes the problem and suggests how users can correct it. This helps users in two ways:
It provides feedback that reassures users that there’s nothing wrong with your application
It puts users in control, letting them decide whether they want to take corrective action and continue using your application or press the Home button and open a different application
If certain circumstances prevent only some of your application's features from working, you can display either a screen or an alert when users activate the feature. Although an alert doesn't allow much flexibility in design, it can be a good choice if you can:
Describe the situation very succinctly
Supply a button that performs a corrective action
Display the alert only when users try to access the feature that isn’t functioning
As with all alerts, the less users see them, the more effective they are. For more information about creating alerts, see “Using Alerts.”
There is no way for an iPhone application to quit/terminate itself. Apple actively advises against it in their Human Interface and/or programming guides (can't remember which exactly) because it would look like a crash to the user.
An app should not terminate by itself.
Also, avoid showing an "exit screen" that prompts the user to quit the app manually as in iOS4, the app might stay open in the background and your user would be stuck in that exit state.