The Cardcase application lets you know if you approach a shop which you have a previous relationship with (if you've set up a tab for payments there etc.).
If background running applications cannot be started automatically on device boot, how does this app therefore work?
Edited to make my question clearer: I am not asking how to monitor for location changes or how to monitor for location changes in the background. My question is, if the user install this app, then adds some tabs for some locations, then they reboot their iPhone, then how can this app subsequently notify them when they approach a location if application launch on boot is not supported?
Must this application (and indeed any other application) be dependent upon it being launched explicitly by the user following every device reboot?
You can do this with region monitoring. You register regions that you would like to monitor with this method on CLLocationManager:
- (void)startMonitoringForRegion:(CLRegion *)region desiredAccuracy:(CLLocationAccuracy)accuracy
Then even if your app is not running, it will be launched in the background as the user enters or leaves the region.
From Apple's docs:
If you begin monitoring a region and your application is subsequently
terminated, the system automatically relaunches it into the background
if the region boundary is crossed. In such a case, the options
dictionary passed to the application:didFinishLaunchingWithOptions:
method of your application delegate contains the key
UIApplicationLaunchOptionsLocationKey to indicate that your
application was launched because of a location-related event. In
addition, creating a new location manager and assigning a delegate
results in the delivery of the corresponding region messages.
EDIT
Just tested this with my own app. Rebooted my phone before leaving the office, and the app was launched on my drive home as usual. So yes, this definitely survives a reboot.
Hope that helps.
This works for geo-fencing apps (apps that use startMonitoringForRegion).
My guess is that when you install apps using this class, the responsible iOS framework automatically registers an launchd script for the app background service startup inside iOS.
Of course this is all done automatically as you don't have fine control on iOS launch services unless you're jailbroken.
You can use the startMonitoringForRegion on your app, jailbreak your device and check on launchd to check how this works under the hood.
Related
I'm developing a simple application that when i press one button, creates a Local Region. Till this is all ok, the app creates Region and notify correctly when i enter in this, even if my app is in background. Now, i think that my question is so tricky. Can i create an app that while it's running creates a local region, but even when it's NOT running notify that we are entered in the region created before? I want to know if there is a method that allow me to monitoring significant location changes, even when the app is closed. And if this method recognize (with the app still closed) that i'm entered in a Local Region, starts to uploading my location (i don't know, with a costant interval or something).
You can set a region and your app will get notified via the UIApplication's Launch Options. This will launch you app and you can handle the event then. There will be some limits what you can do when the app is still in the background.
This article from Apple should be helpful: https://developer.apple.com/documentation/corelocation/monitoring_the_user_s_proximity_to_geographic_regions
Edit: You also must enable Location updates for Background Modes in the Capabilities.
I am sending user location at n time on server for tracking. Working fine in foreground and background mode. But my question is bit more theoretical.. Does my location update service remain running after i force close the app on the device?
I know i can check it on server, But sorry i don't have server access permission. So i have to be sure in which scenario my location service will stop running.
Yep it will continue to be updated when the application is sent into the background. For some official docs check here under the "Getting Location Events in the Background (iOS Only)" section.
Also, under special circumstances you can register your application to have a true background process running like Android allows. So when the user kills the background application, your app doesn't really die. The background process continues to work. Apple will only allow apps that have a necessary reason for this though. Such as a turn by turn navigation app (example from the docs).
Yes, if the application is removed from background then location update will be stopped.
iOS will only restart an app after a force close if its uses region monitoring or the significant-change location service. From the iOS Location and Maps Programming Guide section on Getting the User’s Location:
If your app is terminated either by a user or by the system, the system doesn’t automatically restart your app when new location updates arrive. A user must explicitly relaunch your app before the delivery of location updates resumes. The only way to have your app relaunched automatically is to use region monitoring or the significant-change location service.
iOS only restarts the app if it has Background App Refresh enabled:
when a user disables the Background App Refresh setting either globally or specifically for your app, the system doesn’t relaunch your app for any location events, including significant-change or region monitoring events.
I have an IOS application that uses location services.
I know that applications using location services can execute in the background.
However, I don't want my app to run in the background. If the user isn't watching it, it should not power.
Is this going to happen naturally (i.e. something special is needed for apps using location services to continue to operate in the background?)?
If not, what do I need to do to ensure the app using location services suspends when it goes into the background? If so, what? And what would need to be done to restore the app?
Thx
No problem - just do nothing. When the user switches away from your app (to another app, or locking the screen) your app will be suspended.
However, to make absolutely sure you don't do any location in the background, use the applicationDidEnterBackground and applicationWillEnterForeground notifications (or the corresponding app delegate methods) to stop and restart location updating.
Ok, so I currently have an app where I register a geofence to be monitored using the CLLocationManager startMonitoringForRegion method. This works fine when the app is in the foreground and background.
I also have the appropriate plist values set:
UIBackgroundModes :{location}
UIRequiredDeviceCapabilities: {location-services}
What doesn't work
After a device restart, the app is not being relaunched. I can force this to happen if I set startMonitoringSignificantLocationChanges before entering background. But this method uses much more battery life and I don't need the location all the time, just whenever I break a geofence.
The docs for regions say:
In iOS, the regions you register with the location manager persist between launches of your application. If a region 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. When relaunched, all of the regions you configured previously are made available in the monitoredRegions property of any location manager objects you create.
Question
Is it possible (when using geofencing regions) to have the system restart my app AFTER a system reboot, WITHOUT using startMonitoringSignificantLocationChanges ?
Edit: I am targeting iOS6 & iOS7
Answering my own question here.
While you do need to use the startMonitoringSignificantLocationChanges to get the system to wake up the app after a device reboot. Nothing will wake up the app if the user has force closed it.
For my purposes, I did not need to set UIBackgroundModes to location. This setting is usually used for applications that only need fine-grained location updates (E.g. using startUpdatingLocation). Setting the background mode is not required when using startMonitoringSignificantLocationChanges.
The scenario is as follows. I have an iOS app that uses the CLLocationManager's region monitoring feature to notify the app when a predefined geographic region is entered. The way region monitoring works, the app can be notified of a user entering a region, even if the app was previously terminated. Basically, the operating system will launch the app (without bringing it to the foreground), when the region is entered, and gives the app a chance to respond to the region being entered.
What I am trying to do is log an event using Flurry when the region is entered. Currently, it does not seem to be working, as the events are not showing up in Flurry, even after several days. I should note that I have tested both i) that Flurry event logging is otherwise working OK when the app is launched as normal by the user and ii) that my app is indeed receiving the region entered and exited events (I use local notifications each time the region is entered or exited).
My suspicion is that it has something to do with the application delegate lifecycle differing when the app is launched as a result of entering a region versus when the app is launched as a result of the user starting it. My first suspicion was that application:didFinishLaunchingWithOptions: was not called when the app was launched in the background. Because my call to [Flurry startSession:#"my_key"] is in the application:didFinishLaunchingWithOptions: method, this would have explained things. However, the Apple documentation for startMonitoringForRegion:desiredAccuracy: suggests that application:didFinishLaunchingWithOptions: is in fact called:
If you begin monitoring a region and your application is subsequently
terminated, the system automatically relaunches it into the background
if the region boundary is crossed. In such a case, the options
dictionary passed to the application:didFinishLaunchingWithOptions:
method of your application delegate contains the key
UIApplicationLaunchOptionsLocationKey to indicate that your
application was launched because of a location-related event.
Although I'm using startMonitoringForRegion: and not startMonitoringForRegion:desiredAccuracy: (deprecated), I'm assuming that both call application:didFinishLaunchingWithOptions:. I then read a note in the Flurry documentation about startSession: (emphasis mine):
This method serves as the entry point to Flurry Analytics collection.
It must be called in the scope of applicationDidFinishLaunching. The
session will continue for the period the app is in the foreground
until your app is backgrounded for the time specified in
setSessionContinueSeconds:. If the app is resumed in that period the
session will continue, otherwise a new session will begin.
Note:
If testing on a simulator, please be sure to send App to background via home button. Flurry depends on the iOS lifecycle to be complete for full reporting.
So, my suspicion is that even though I am testing on a real device, the app never gets "sent to the background" because when it launches it never enters the foreground to begin with. Can anyone clarify whether this is the reason for my logged events never showing up, or whether there is perhaps some other reason? And, is there a workaround for this?
So I contacted Flurry support and this is what I heard back:
So, at present its not possible to record / log events while the app is in the background.
Our engineering team is working on a solution to this and this should be available in one of the future versions of our SDK, in probably a months time.
So I guess we'll wait and see.