When an app uses startMonitoringSignificantLocationChanges while backgrounded or when terminated, if a significant change is detected Apple states that it will bring the app back into the foreground. But, will I still be able to get the value of an ivar (previously set when the app was in the foreground) within the didUpdateToLocation CLLocationManager delegate method? Or is it lost?
If it is lost, what is the best way to persist those values after the app has terminated/backgrounded and brought back into the foreground by the location manager?
Yes of course you will. The only way you'd lose the value of that ivar is if your app has actually quit and been relaunched, at which point you're not simply coming back from the background.
Related
If i have a array of employees for example in my viewcontroller. Then I get the notification of low memory and the app is also not the active one.
At this point I should save the list of employees in a DB right ? so that when the user reactivate the app again, it will go through the viewDidLoad and from here I can reload the data from the DB?
Is this a good strategy?
I'm fairly new into iPhone dev.
You should save any unsaved changes as soon as your app enters the background. Your app could be terminated at any point in the background without ever receiving any notifications of any kind. If your data isn't saved, it will be lost when the user restarts the app.
With regard to memory warnings, these are more likely to happen in the foreground. Once your app is in the background, it is suspended and won't get any notifications. If your app is running under iOS 5 or earlier then a memory warning could result in a view controller's viewWillUnload method being called. When that view controller needs to be displayed again, its viewDidLoad will be called again. Under iOS 6, this doesn't happen anymore. viewWillUnload is deprecated.
I would like to know how i can detect when an application is about to be terminated. I mean really terminated, not just going into background mode. I have used this event, and it doesn't fire :
applicationWillTerminate
What i would really like to achieve is get some kind of event or notification when the user taps Home twice and presses the red baloon on the app. I don't care about the application going into background mode, there are a couple of events that handle this properly and they all work fine.
I need this so that i can "inform" my server to stop sending push notifications to APNS for apps that are terminated and aren't running in the background.
If you know of an easier way to achieve this, i'd be glad to hear :)
Thank you
Register your object (view controller, etc.) to listen for the UIApplicationWillTerminateNotification notification, and/or override the application delegate's -applicationWillTerminate: method and put your code there.
Angel, what you're asking for cannot be done. The app will be terminated with SIGKILL. Unstoppable, not catchable, no notifications. There is no difference between a system-initiated termination or one requested by the user.
You'll get applicationWillTerminate only if your app doesn't support background processing.
From UIApplicationDelegate docs on the matter:
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.
Seems to me that unless your background process is actively doing something in the background (not being suspended) it the applicationWillTerminate method will never get called.
I guess it depends what you definition of "being in the background" is.
IIRC it goes like this:
On start:
didFinishLaunchingWithOptions
applicationDidBecomeActive
Pressing home:
applicationWillResignActive
applicationDidEnterBackground
Coming back from home screen:
applicationWillEnterForeground
applicationDidBecomeActive
applicationWillTerminate is called when your application exits due to a call or the OS kills it for some reason.
Is there any possiblity for reacting to the event that a user kills your app via the multitasking bar if it has moved to the background? According to my observations, applicationWillTerminate: does NOT get called.
It seems to me that there is no possiblity for cleaning up before quitting in this case.
If an app needs to do any cleanup or shutdown, under iOS 4.x it should do this when the app's suspend delegate gets called, just before the app gets sent to the background, since there is no guarantee that the app will ever get any run time again, either due to user action or memory cleanup.
If the app's Deployment Target also includes iPhone OS 3.x, then it should also do cleanup in its terminate delegate, as that will get called instead of suspend.
It should get called. Are you depending on NSLog to tell you when it does get called? When an app goes into the inactive state by pressing the home button then any further NSLogs are not printed to the console. You could try showing a small UIAlertView to see of it does get called instead.
I want to detect application states and send it to the server. In the new OS4, with multitasking there are some methods available to help detecting the states:
application:didFinishLaunchingWithOptions:
applicationDidBecomeActive:
applicationWillResignActive:
applicationDidEnterBackground:
applicationWillEnterForeground:
applicationWillTerminate:
I read that now, we have to use applicationDidEnterBackground instead of applicationWillTerminate. My problem is that i need them both.
When the user send the app to the background, it has the state sleep. But when the user close the app ( from the multitask bar ) the state is closed. So i need to detect both, when the user send the app to the background and when the user ( or the system ) close it.
Is there anyway or workaround to make this?
I try subscribing to UIApplicationWillTerminateNotification but it doesn´t work.
Thanks in advice.
The application will quit notification is no longer fired on iOS 4 (as I am led to believe).
When the user hits the home button, the app is sent to the background, and you will get the did enter background notification. But when a user closes the app from the multitask bar, or if the system closes it, the app is sent a SIGKIL message and quits immediately, firing no notifications or delegate methods.
I have an app (a game) which saves data: game state, high scores, achievements, etc. Currently the app delegate does this on applicationWillTerminate:. After playing around with iPhone 4 for a bit, it seems that applications pretty much never terminate: they just run in the background forever, unless the user goes out of their way to quit them, or restart the phone.
So my question is, should I find another place to save my data, and if so, when?
To minimize the amount of time spent in the delegate method call, you should find a place that makes sense to save during the game (level completion, checkpoints, etc). You can also add a new delegate method to your application delegate which will be called when your application transitions to the background where you can duplicate some of the things you may have done previously in applicationWillTerminate:. The new delegate method to implement is -applicationDidEnterBackground:.
You will also receive a notification that the user switched back to your app as applicationWillEnterForeground:.
you can do so in the views diddisappear delegate method
-(void)viewDidDisappear:(BOOL)animated
{
//CODE FOR SAVING
}
There are 2 App delegate methods you can use
applicationDidResignActive: //pausing the app, used when a msg comes up. if multitasking this wont help
applicationDidEnterBackground: // called in iOS 4 for when the app is in the background
you can see when it loads into the foreground using
applicationWillEnterForeground:
check out the reference for more info
You should save in applicationDidEnterBackground. Make sure to wrap your saving code with – beginBackgroundTaskWithExpirationHandler: and endBackgroundTask, since without that, you have less than a second (or something like that) before execution suspends.