What do you all recommend as the best location in an iphone project to dump data collected from the user to a local file? Would you say that applicationWillTerminate is a good option?
Thanks!
A better option on iOS 4.x is applicationDidEnterBackground:
Indeed, according to Apple docs, an application in the background can be terminated at any time due to low memory conditions. Therefore, the suggestion is making persistent any state information at the moment the app enters background.
An excerpt from the UIApplicationDelegate protocol:
You should use this method to release shared resources, save user data, invalidate timers, and store enough application state information to restore your application to its current state in case it is terminated later. You should also disable updates to your application’s user interface and avoid using some types of shared system resources (such as the user’s contacts database). It is also imperative that you avoid using OpenGL ES in the background.
Your implementation of this method has approximately five seconds to perform any tasks and return. If you need additional time...
Also from Apple Docs for applicationWillTerminate:
For applications that do not support background execution or are linked against iOS 3.x or earlier, this method is always called when the user quits the application. For applications that support background execution, this method is generally not called when the user quits the application because the application simply moves to the background in that case. However, this method may be called in situations where the application is running in the background (not suspended) and the system needs to terminate it for some reason.
Therefore if you specifically request to not support backgrounding for your app or you link against iOS 3.x you should consider persisting in both places (applicationWillTerminate and applicationWillEnterBackground) to catch situations as well.
Related
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.
While the device is powered on, is it possible for iOS to automatically terminate my app (calling applicationWillTerminate:) while it's in the background?
I'm also curious what happens in two other cases, three in total:
Device is powered on
Device is powered off
Device loses battery
I'm asking because I want to know how often applicationWillTerminate: is likely to get called. I want to know this because that's where I'm registering for remote notifications. And if there's a failure sending the device token to the server, I want to know how likely it is that that method will get called again (i.e., retry sending the device token to the server).
If your application supports multitasking (the default for anything linked against iOS 4.0+), this method will almost never be called. The documentation says it may be called in cases where the application is running in the background and the system wants to terminate. However, in my experience, I've only ever seen this actually called when running a music app that's actively playing music in the background and the system is jettisoning everything. In cases where I have background tasks running (not music, but short-term background tasks), I've seen the app terminated without this method being called.
I wouldn't ever rely on this being called and try and do all the clean-up you need to do in your delegate methods for transitioning into the background and your background task completion blocks (which do get executed for at least a few seconds before the app gets jettisoned).
Not only can iOS terminate your app automatically, but the user can kill it manually. In fact, the only time the user can kill your app is when it's in the background. Furthermore, when your app is "in the background" it's more likely to be suspended than actually running, so don't count on doing a lot of processing when you're not the foreground app.
As for how likely it is that you'll get -applicationWillTerminate:, that'll depend on the user and how they're using their device. You should handle it appropriately when you get it, and go about your business otherwise.
When memory is running low, iOS can shut down your app, calling applicationWillTerminate.
The docs say this about the method:
... However, this method may be called in situations where the application is running in the background (not suspended) and the system needs to terminate it for some reason.
Check out iOS Developer Library : iOS App Programming Guide : App Termination.
I've just been reading this post on notifications being sent to apps running in the background :
Not getting didReceiveMemoryWarning when app is in the background
My question is that since an app in the background will not act on a didRecieveMemoryWarning until it enters the foreground again, what is the recommended way to free up memory in your app if it is running in the background when the memory notification is sent - or is this not possible ?
In iOS 4.0 and later, - (void)applicationDidEnterBackground:(UIApplication *)application method is called instead of the applicationWillTerminate: method when the user quits an application that supports background execution.
You should use this method to release shared resources, save user data, invalidate timers, and store enough application state information to restore your application to its current state in case it is terminated later.
You should also disable updates to your application’s user interface and avoid using some types of shared system resources (such as the user’s contacts database). It is also imperative that you avoid using OpenGL ES in the background.
Your implementation of this method has approximately five seconds to perform any tasks and return. If you need additional time to perform any final tasks, you can request additional execution time from the system by calling beginBackgroundTaskWithExpirationHandler:. In practice, you should return from applicationDidEnterBackground: as quickly as possible. If the method does not return before time runs out your application is terminated and purged from memory.
If your app is running in the background (because it is, for example, a Voice over IP app that is allowed to run in the background), it will receive memory warning notifications in the same way as if it were running in the foreground, and you should deal with them accordingly.
However, if your app is suspended in the background, it won't receive memory warnings or other notifications. Your job is to free as much memory as possible before your app enters the background. Once you're in the background, you have no way to do anything anymore. The OS will decide whether to kill your app or not (without notifying you again) at its discretion.
I am working on an iphone game app. I dont want to use core data or nsuserdefaults to store user data. instead i want to keep all activities in memory and then send it to server when user goes back to previous screen, ends game or presses the home button of iphone. Now everything works fine but i am not able to sync user data when user presses home button. I have implemented the appilcationWillTerminate method in my delegate class but its not working out for me as the method is not get called when I press home button of iphone. Can anyone please tell me how to achieve this task?
best regards
What about this method:
Tells the delegate that the application is now in the background.
- (void)applicationDidEnterBackground:(UIApplication *)application
From Apple Docs:
In iOS 4.0 and later, this method is called instead of the applicationWillTerminate: method when the user quits an application that supports background execution. You should use this method to release shared resources, save user data, invalidate timers, and store enough application state information to restore your application to its current state in case it is terminated later. You should also disable updates to your application’s user interface and avoid using some types of shared system resources (such as the user’s contacts database). It is also imperative that you avoid using OpenGL ES in the background.
Your implementation of this method has approximately five seconds to perform any tasks and return. If you need additional time to perform any final tasks, you can request additional execution time from the system by calling beginBackgroundTaskWithExpirationHandler:. In practice, you should return from applicationDidEnterBackground: as quickly as possible. If the method does not return before time runs out your application is terminated and purged from memory.
You should use NSUserDefaults to store data about the application state. Then, when the application re-starts, you can load the data from NSUserDefaults to recreate the previous state. However with the new multitasking this is not as necessary as it used to be a couple of years ago.
I am writing a utility where data for games is written to disk at various stages throughout the game (including, but not relying on when the app exits). My question is currently I am doing my initial load using application:didFinishLaunchingWithOptions: but was curious about what happens when the application goes into the background / is suspended etc. Currently I am assuming that all my loaded data will hang around and I only need to do a load when the application initially loads. Is this the case or can iOS flush my stored data and I should look at checking if a load is needed in say applicationWillEnterForeground:
Also its a pretty small amount of data (20 small NSArray objects) but I guess I could always save and clear the data store when I get applicationDidEnterBackground: and reload on applicationWillEnterForeground: Or given that its just a small about of data would I be better to just leave it resident at all times?
Save your state when you get applicationWillResignActive:
That happens when you go into the background, or get a phone call, or several other interruptions occur. This is a better place than applicationDidEnterBackground: since that doesn't get called in devices running pre iOS 4.0 (which only matters if you support ios < 4).
Once your app goes into the background or is interrupted it can get killed without any warning, so this is your last sure chance to save/flush state data.
There is no need to reload data when you return to the foreground. If that happens, your app is still in memory with its data still there (except possibly view(s) may have been unloaded)
I advice that you always save your in-memory data when your app moves to the background. When in the background iOS may terminate your app when it needs the memory and you won't be notified when that happens.