Will Core Motion framework work while the app is in the background?
The Core Motion framework allows access to historical data for CMPedometer data, so if your app is only using this there is no need to run in the background.
I have been playing around with CM the last week and in my testing if you have an active query running when your app is sent to the background, the query handler receives a flood of events (that occurred while the app was suspended) upon returning to the foreground. I don't know how many events will be cached, and I haven't seen anything in the docs about this.
This behaviour seems to be sufficient. I can't think of a use case for Core Motion where you need constant background access, historical CMPedometer data doesn't suffice, and fits within the App Store guidelines.
Depends on your definition of working... Will Core Animation need to continue running or are you expecting the view to be frozen? When an app runs in the background only certain processes are allowed to run. (Notifications for example).
For the most part the application UI, and by extension is paused until you trigger applicationDidBecomeActive. Once that starts up again it should resume, but again not continue running in the background. Same can be said for most games on iOS running OpenGL, it's paused until the app is active again.
one of the apps- moves that is used to track your walking steps is quite amazing, because even you make it into background or killed, it can indicate the steps you walked. So some internal mechanism of gyroscope and GPS and other sensors can carry on when the apps are killed.
In order to let your app run in the background, you have to declare it as a background task. The problem is that there are only a few UIBackgroundModes ... and motion isn't one of it.
A workaround could be to enable the UIBackgroundMode location, which is intended to let users know about their location even if the app is in the background. You could then wrap your motion logic within. Nevertheless, the clear drawback of this is that it involves usage of the GPS, which will drain the battery significantly...
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.
I am using CoreLocation to determine user's location to calculate the distance and show the route on the map. To minimize battery usage I am turning off GPS after getting location and turning it on again after 1 minute. When the application is active everything works fine, but after sending it to background and turning off GPS, the app seems to be inactive at all, it doesn't output anything (using NSLog()). I have added directive to info.plist file to allow the application to run in background. When I don't turn off the GPS in background the app works as well as in foreground.
So my question is the following: does GPS always need to be turned on in background to prevent the application to be suspended or there is another workaround (because the turned GPS drains the battery)?
P.S. I am new to iOS and mobile development at all, so maybe there are some tips that I have to know.
See http://developer.apple.com/library/ios/#documentation/iphone/conceptual/iphoneosprogrammingguide/ManagingYourApplicationsFlow/ManagingYourApplicationsFlow.html
Apple does not support long running background task in general.
This does only work for specific tasks:
audio,
location,
voip,
newsstand-content,
external-accessory,
bluetooth-central and
bluetooth-peripheral
When you do not use any of that, your app could be suspended.
In your case ypu have specified location, but disabled the location update. Then for apple there is no reason to keep your app in background mode.
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.
I am making an app, which needs to keep tracking user's location every time. It can also work in the background mode. The issue is When I use other apps for several times. The other app may cause lots of memory. My app sometimes be terminated by the system. There are no crash logs. So I want to know some reasons. Is there any way to avoid my app to be terminated? Very appreciate for your help.
You can't prevent the app the be terminated, but what can you do best to keep it alive is when it enters in background free as much memory as you can - cached images, files... Also stop any running timers, UI updates and everything time consuming. By following the MVC rules, the best implementation is to create a separate class (model) that's only responsible for location updates (with CLLocationManager inside, and the class implements its delegation methods). So the only thing in background you should do is collecting the location points received by the CLLocationManager and nothing else. Also implement the method -applicationWillTerminate in you AppDelegate. This method is called only when the app is in background and it's going to be terminated (either by the OS or the user) and inside persist the location points in CoreData for example or however you do it... I have such an approach and so far my app has lived for 24h (with charging of course) without being killed.
App running in the background depend upon memory usage, battery life etc.When there are many app running in the background, your app may get terminated.I do not think you can run your app permanently in background.
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...