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
Related
Am developing application for calculate count of user moved steps and draw the user activities in the map. And we are using UIAccelerometer delegate for receive acceleration-related data from the onboard hardware. So I need to receive acceleration-related data when the application in background mode too. Last time one of my application got rejected because of using location service in background, Apple suggested me like "you can only use this background mode if your app truly needs this information to provide value for the user". Kindly suggest the best approach for this application.
You cannot run accelerometer in background.
You can track user's location in background... however, if you just keep tracking it and do nothing with that info.. apple is going to reject it and tell you to just get the lates location when app comes to foreground.
what you can try is.. update the user of total distance covered etc on a regular basis (like run keeper) and this will justify tracking location in background.
But first, you can try appealing to the review board explaining that you need to track location in background because you show entire route travelled by user when app comes to foregraound. and compare this to existing apps like run keeper and if you are lucky apple may approve your application without any changes...
This can easily be done.
What happens in that iOS put your application in halt state when your application is not in running in foreground state.
You just need to register your application for background execution.
Refer :
http://dcraziee.wordpress.com/2013/05/20/background_ios/
Also refer :
iOS background application network access
for apple policies about using location service.Which states that you can use location service in background.
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.
I have to develop a kind of GPS navigation application that needs to constantly keep track of the position of the user, which is moving by car.
In the specific, I don't have to display the current location on a map but just to record its position with the best possible precision in order to calculate the total distance traveled.
Of course the application needs to continue its work in background if the user switch to another app, a phone call come in or something like that…
From the tests I have made and from what I have learned from this useful post (and from the documentation), it seems to me that the best choice in this case is the Standard location service, with the application configured with the UIBackgroundModes = location in the .plist file.
In this way it will continue to receive the location updates even if in background and it will never be suspended by the OS (this is actually true only if [locationManager startUpdatingLocation] has been called). This is also confirmed by this guys.
I have personally verified that is true simply by running the app with Instruments and the Memory monitor module where you can see the various flags about the app states, putting the app in background first with UIBackgroundModes set to location and startUpdatingLocation active, and after without it.
1) I'm now wondering what to do when the app is terminated when it is tracking the position. I don't want to loose any location updates so I need to wake up it again whenever a new update is available.
The documentation say:
Important: The applicationWillTerminate: method is not called if your
app is currently suspended.
But because in my case it will be never suspended (it will stay in background but not suspended), my logical conclusion is that applicationWillTerminate will be always called and so I could register for a Significant location update or Region monitoring inside of this method in order to be waked up and then restart the Standard location service.
Is applicationWillTerminate the right place to put this code?
2) An application working in background but not suspended could be terminated by the OS for no other reasons than a very low memory condition or for my app don't properly respond to a memory warning? (the user could also manually close it). I was concerned if applicationWillTerminate wouldn't be called in some way.
3) Could Apple not approve an app which constantly use the standard location services in background because of its quick battery drain?
Have you ever had approve problems for similar apps?
since you are asking many questions which you shoukd not do here, i cam give you only aswrs to a part of it.
if the app is terminated, then you cannot restart it anymore.
This is usually the case when the user terminates the app.
Dont worry Apple ( ios) will not terminate your app. your app will not use much memory, games with huge bitmap graphics are more likely to be termin.
evry gps app will drain the bat. that is not a reason for not aproving.
suspended means that app is not in background mode, it is sleeping. you will not receive Gps, so there is no need to call you on terminate. you have to save data before, see the apple docu on background modes and app life cycle.
My question is: Is CLLocationManager continue running, while my app is inactive?
Yes, if CLLocationManager is first called startUpdatingLocation method, and in the AppName-Info.plist file is added Required Background Modes -> App registers for location updates
Yes, it could. You have two options for handling location service events when your app is suspended, which can be read at the article: Getting the User’s Current Location.
As noted:
There are two different services you can use to get the user’s current location:
The standard location service is a configurable, general-purpose solution and is supported in all versions of iOS.
The significant-change location service offers a low-power location service for devices with cellular radios. This service is available only in iOS 4.0 and later and can also wake up an application that is suspended or not running.
Also, as noted at the bottom of this article in the section "Getting Location Events in the Background":
If your application needs location updates delivered whether the application is in the foreground or background, there are multiple options for doing so. The preferred option is to use the significant location change service to wake your application at appropriate times to handle new events. However, if your application needs to use the standard location service, you can declare your application as needing background location services.
An application should request background location services only if the absence of those services would impair its ability to operate. In addition, any application that requests background location services should use those services to provide a tangible benefit to the user. For example, a turn-by-turn navigation application would be a likely candidate for background location services because of its need to track the user’s position and report when it is time to make the next turn.
There are some important subtleties with this (as of iOS 7.1):
The Location Update background mode should NOT be used if you are just looking for significant change and region enter/exit events. You will still receive these events even if the background flag is NOT set, and you will save a lot of battery at the same time.
If you do the above, you need to be mindful of limited permitted background time. If you don't take care to wrap up network requests etc. in the permitted time, you will network transaction failures.
You should ONLY use the location background mode if you need to use detailed location tracking (e.g. -startUpdatingLocation), in which case this background mode will keep your app awake.
Using the location background mode when not getting detailed location will piss off your users and may get your app rejected during the review process (depending on how you use location throughout your app).
Your app may be killed at anytime by the OS if you do not have the background location mode set, so you will need to be sure to properly re-initialize your CLLocationManager instance in applicationDidFinishLaunching or applicationWillFinishLaunching in order to get the subsequent updateLocation or didEnter/ExitRegion delegate call. Just because location wakes up your app with a location update, it does NOT magically re-create your CLLocationManager without you programming it!
Hope that helps!
To disable CLLocationManager while the app is in backround mode you simply must not add the
"App registers for location updates"
in the
"Required background modes"
key of the info.plist file.
I suggest to use the significant-change location service instead of the standard location service whenever possible, to preserve device battery.
I am writing an application that records a users position at regular intervals whilst walking. I am using an NSTimers to schedule "startUpdatingLocation" followed by calling "stopUpdatingLocation" shortly afterwards to save as much battery as possible.
I want the user to be able to start the application and lock the phone thereby putting the application in an inactive state. My question is when this happens my application (when running via Xcode) seems to continue as normal, but I am curious if there are any differences in the way the application runs in this state as apposed to when the application is running as active?
From the docs it only mentions "applicationWillResignActive" with regards to the application passing through that state on its way to the background. I am more interested in how an application behaves when a used locks the UI and puts the phone away, I just want to make sure its going to keep doing what it should be doing or do I need to take extra measures?
When you app hits applicationWillResignActive it can continue to receive location updates if you use the UIBackgroundModes option in your apps info.plist.
Add the location key.
It is important that you do not use a timer in the background as timers will run but hold their "fire" until the app becomes active again. Thus you will only get one read when the user comes back to the app. The GPS location accuracy level is what will drive how much the battery is affected.
In your app description in the App Store, Apples requires:
Continued use of GPS running in the
background can dramatically decrease
battery life.
You app will not be allowed to go live until the above text is in the description for the user to read.
You should definitely be testing this on a device. The simulator doesn't auto-lock, for instance.
applicationWillResignActive is called when the user presses the home button, when another app fires a notification the user accepts (including when a call comes in), and when the device locks.
Look into the multitasking documentation, and what it has to say about background location updates.
My suggestion is that you conserve the user's battery by:
- starting a timer, which when fired, starts location updates (and stops the timer)
- when you get an adequately-accurate position record, stop location updates and restart the timer
- if location updates fail, restart the timer for a longer period. Maybe they're underground.
The most efficient approach is using significant location update service while your application is in the background or the screen is locked on your app. You might get one update every ten minutes or so.
Remember also, the user can disable your app's location services permissions. Especially these days...