What is the delegate method for detecting when application was closed.
I mean when user tap this button:
I know about method below:
- (void)applicationDidEnterBackground:(UIApplication *)application;
- (void)applicationWillEnterForeground:(UIApplication *)application;
But they work not as I expected in my case. For example I have used my app and I have navigated to some screen. In case when I lock screen and go back to app the app calls applicationWillEnterForeground but I don't need this, because I am still on this view (for example Test Screen View)and I don't need to check any changes. But in case if my app closed I begin to navigate from start app for example Home Screen. So if my app was closed and I am on Home Screen I need to check if in previous time I had some actions (for example if I passed test on Test Screen View) and present this view controller (ONLY IN CASE IF I CLOSED APP NOT JUST LOCKED IT OR ENTER BACKGROUND).
Thanks for help.
You can't detect this. From the iOS App Programming Guide ("App Termination" heading):
Important: The applicationWillTerminate: method is not called if your app is currently suspended.
Even if you develop your app using iOS SDK 4 and later, you must still
be prepared for your app to be killed without any notification. The
user can kill apps explicitly using the multitasking UI. In addition,
if memory becomes constrained, the system might remove apps from
memory to make more room. Suspended apps are not notified of
termination but if your app is currently running in the background
state (and not suspended), the system calls the
applicationWillTerminate: method of your app delegate. Your app cannot
request additional background execution time from this method.
You can't. When your app is killed in this manner, it is not told anything. The app is killed by the OS with no warning of any kind.
When your app enters the background, you have no way to know if will be started fresh or simply return to the foreground. Therefore you must properly handle things when the app enters the background.
When the app starts again, restore whatever state you need.
On iOS, you cannot check for that. That is: the process is SIGKILL'ed. One way I know that might be able to work relies on the fact that to kill an app, one has to suspend it first by pressing the home button.
Hence, you can gather your actions as the user uses the app, commit it to a saved place when the user suspends the app. If the user resumes, reset the list and start gathering info again. However, if the user suspends the app and you never get a resume, on the next app start, you can read the list and recover from there.
HTH
You can implement the -applicationWillTerminate: method of your UIApplicationDelegate delegate to respond to termination events. However, it's not guaranteed to be called in all cases, so you should not rely on it being called. According to the iOS App Programming Guide:
If your app is running (either in the foreground or background) at termination time, the system calls your app delegate’s applicationWillTerminate: method so that you can perform any required cleanup. You can use this method to save user data or app state information that you would use to restore your app to its current state on a subsequent launch. Your method has approximately 5 seconds to perform any tasks and return. If it does not return in time, the app is killed and removed from memory.
Important: The applicationWillTerminate: method is not called if your app is currently suspended.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 2 years ago.
Improve this question
I know there exists a similar question but I think that question is a lot more general and does not answer on the specific details that I'm trying to find out.
I've read the Apple documents, but still I'm a bit confused on when exactly these methods are triggered. From the Apple documents, it seems there are the following state transitions that are possible for an iOS app:
App terminated in the foreground (for example double tap the Home button and swipe up the app): pretty sure applicationWillTerminate is triggered in this case, actually this is the only case that I'm not too confused about.
App switched to the background while still running in the background (for "apps that support background execution" to quote Apple documents): applicationDidEnterBackground is triggered? applicationWillResignActive is triggered or not?
Background running App gets terminated: applicationWillTerminate may(?) be triggered according to the Apple documents... so it may or may not be triggered at times?
App switched to the background and immediately suspended: applicationDidEnterBackground and applicationWillResignActive are both triggered?
Background running App gets suspended: applicationWillResignActive is triggered? Or nothing gets triggered?
App that "does not support background execution" gets switched to the background: applicationWillTerminate gets triggered according to Apple documents? But what exactly does this actually talk about?
App crashes in the foreground: nothing gets triggered in this case I guess?
Background running App crashes: also nothing gets triggered in this case right?
Background suspended App gets terminated: Again nothing gets triggered I guess?
I think the Apple documents are either somewhat vague or downright confusing in explaining those methods. Sometimes they talk about "apps that support background execution" vs. "apps that do not support background execution", sometimes they talk about "running in the background" vs. "suspended", sometimes they just say things like "the user quits the app and it begins the transition to the background state" or "incoming phone call or SMS message", which are real-world use-cases instead of technical concepts.
So anyone can help explain in more consistent technical terms that when exactly are those methods triggered in specific cases?
EDIT: Not sure why this question is deemed not "focused", as I'm trying to make use of those application delegate methods but after both some personal testing and reading official documents, I'm still at a loss when exactly those methods will be triggered and how may I use them reliably.
Maybe I can elaborate more by borrowing some stuff from PGDev's answer, so there are 5 states an iOS app can be in if I understand correctly:
Not running
Inactive
Active
Suspend
Background
And when the app changes state, some delegate methods may be triggered, but so far from the official Apple documents, it seems very confusing which methods will be triggered during which state transition.
For example I'm not sure what or if any method will be triggered when app goes from state 5 to state 4, and when app goes from state 5 to state 1, and when app goes from state 4 to state 1. Also from the official Apple documents it seems to say that applicationWillTerminate will be triggered if "apps that do not support background execution" are switched to the background, however I have not been able to get any kind of app to trigger applicationWillTerminate by just pressing the Home button.
As it currently stands, I'm not sure if I can reliably utilize those methods to do anything, that's why I hope someone can give a clearer picture on when exactly those methods will be triggered (and not triggered) apart from those vague descriptions in the official Apple documents.
Here is the detailed explanation of how the App Lifecycle methods work.
There exist 5 states in the the lifecycle of the app,
Not running — The app is not running.
Inactive — running in foreground + not receiving events
An iOS app can be placed into an inactive state, for example, when a call or SMS message is received.(Foreground + Not Running)
Active — running in foreground + receiving events
Suspend — running in background + not executing code
Background — running in background + executing code
Next there exist 7 delegate methods that are called whenever the above states are changed in the app's session.
Launch time
application:willFinishLaunchingWithOptions
Method called when the launch process is initiated.
This is the first opportunity to execute any code within the app.
launch process has begun but that state restoration has not yet occurred.
didFinishLaunchingWithOptions
Method called when the launch process is almost done and the app is almost ready to run. Final initialization.
Transitioning to the foreground
applicationDidBecomeActive
app has become active.
Transitioning to the background
applicationDidEnterBackground
This method is called when an iOS app is running, but no longer in the foreground
Transitioning to the inactive state:
applicationWillResignActive
exit from active state to another state
Each time a temporary event, such as a phone call, happens this method gets called
called when app moves to background
applicationWillEnterForeground
about to enter from background -> foreground
Termination
applicationWillTerminate
app is about to terminate.
Force quitting the iOS app, or shutting down the device
This is the opportunity to save the application configuration, settings, and user preferences.
Some flow examples of the order in which the above methods will be called.
Launch app — 1, 2, 3 — willLaunch + didLaunch + didBecomeActive
Press home — 5, 4 — resignActive + didEnterBackground
Open app from background — 6, 3 — willEnterForeground + didBecomeActive
Open task manager — 5 — resignActive
Phone call comes when app in foreground — 5 — resignActive
You can test the execution of the lfecycle methods using the above examples.
I want to fetch location in background even if user forcefully quit the app. Currently my applicationDidEnterBackground method not called when user quit the app. It only works when user simply click on the home button.
Please refer to applicationWillTerminate
By Apple documentation it says:
This method lets your app know that it is about to be terminated and purged from memory entirely. You should use this method to perform any final clean-up tasks for your app, such as freeing shared resources, saving user data, and invalidating timers. Your implementation of this method has approximately five seconds to perform any tasks and return. If the method does not return before time expires, the system may kill the process altogether.
For apps 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 app. For apps that support background execution, this method is generally not called when the user quits the app because the app simply moves to the background in that case. However, this method may be called in situations where the app is running in the background (not suspended) and the system needs to terminate it for some reason.
After calling this method, the app also posts a
UIApplicationWillTerminate
notification to give interested objects a chance to respond to the transition.
If you want to have user's location when app is not in memory, short answer: Impossible.
What is the delegate method for detecting when application was closed.
I mean when user tap this button:
I know about method below:
- (void)applicationDidEnterBackground:(UIApplication *)application;
- (void)applicationWillEnterForeground:(UIApplication *)application;
But they work not as I expected in my case. For example I have used my app and I have navigated to some screen. In case when I lock screen and go back to app the app calls applicationWillEnterForeground but I don't need this, because I am still on this view (for example Test Screen View)and I don't need to check any changes. But in case if my app closed I begin to navigate from start app for example Home Screen. So if my app was closed and I am on Home Screen I need to check if in previous time I had some actions (for example if I passed test on Test Screen View) and present this view controller (ONLY IN CASE IF I CLOSED APP NOT JUST LOCKED IT OR ENTER BACKGROUND).
Thanks for help.
You can't detect this. From the iOS App Programming Guide ("App Termination" heading):
Important: The applicationWillTerminate: method is not called if your app is currently suspended.
Even if you develop your app using iOS SDK 4 and later, you must still
be prepared for your app to be killed without any notification. The
user can kill apps explicitly using the multitasking UI. In addition,
if memory becomes constrained, the system might remove apps from
memory to make more room. Suspended apps are not notified of
termination but if your app is currently running in the background
state (and not suspended), the system calls the
applicationWillTerminate: method of your app delegate. Your app cannot
request additional background execution time from this method.
You can't. When your app is killed in this manner, it is not told anything. The app is killed by the OS with no warning of any kind.
When your app enters the background, you have no way to know if will be started fresh or simply return to the foreground. Therefore you must properly handle things when the app enters the background.
When the app starts again, restore whatever state you need.
On iOS, you cannot check for that. That is: the process is SIGKILL'ed. One way I know that might be able to work relies on the fact that to kill an app, one has to suspend it first by pressing the home button.
Hence, you can gather your actions as the user uses the app, commit it to a saved place when the user suspends the app. If the user resumes, reset the list and start gathering info again. However, if the user suspends the app and you never get a resume, on the next app start, you can read the list and recover from there.
HTH
You can implement the -applicationWillTerminate: method of your UIApplicationDelegate delegate to respond to termination events. However, it's not guaranteed to be called in all cases, so you should not rely on it being called. According to the iOS App Programming Guide:
If your app is running (either in the foreground or background) at termination time, the system calls your app delegate’s applicationWillTerminate: method so that you can perform any required cleanup. You can use this method to save user data or app state information that you would use to restore your app to its current state on a subsequent launch. Your method has approximately 5 seconds to perform any tasks and return. If it does not return in time, the app is killed and removed from memory.
Important: The applicationWillTerminate: method is not called if your app is currently suspended.
In my application I want to get notified when the instance of the application is deleted.
Even though I can easily get what I am asking simply by googling, I can't find anything useful to me. May be the synonym i'm using deleting the app instance (deleting the app from the list shown at the bottom of the screen when double-clicking the home button in IPad and I'm looking for the UIAppdelegate method called in response to that action).
Is there a way of knowing this?
This is when your app gets killed, either by the user (removing from the task bar) or by the system, to reclaim memory. There's no callback for it. You never get informed that it's going to happen or has happened.
Yes. The - (void)applicationWillTerminate:(UIApplication *)application will be called.
It'll call when user quits the application from the taskbar if and only if your application supports background tasks else it'll be called when user presses the home button to hide your app.
applicationWillTerminate:
Tells the delegate when the application is about to terminate.
- (void)applicationWillTerminate:(UIApplication *)application
Parameters
application
The delegating application object.
Discussion
This method lets your application know that it is about to be
terminated and purged from memory entirely. You should use this method
to perform any final clean-up tasks for your application, such as
freeing shared resources, saving user data, and invalidating timers.
Your implementation of this method has approximately five seconds to
perform any tasks and return. If the method does not return before
time expires, the system may kill the process altogether.
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.
After calling this method, the application also posts a
UIApplicationWillTerminateNotification notification to give interested
objects a chance to respond to the transition. Availability
Available in iOS 2.0 and later.
Reference : UIApplicationDelegate
Our iOS app retrieves new app data every time it is freshly started i.e. not resumed from the background. App data is updated periodically every couple of months via web services so this is generally fine.
However, there may be edge cases where the user's iOS device - iPad, specifically - may keep the app suspended in the background for an extended period of time - potentially indefinitely.
Is it possible to mitigate this edge case by telling iOS "please release this app if it has been suspended for more than a few hours"?
The issue you describe is due to poor app design or a poor understanding of app architecture. If you need to refresh app data whenever the app becomes active you can simply call your update function off of the UIApplicationDelegate event (or register for a notification), specifically:
applicationDidBecomeActive:
Tells the delegate that the application has become active.
- (void)applicationDidBecomeActive:(UIApplication *)application Parameters
application
The singleton application instance.
Discussion
This method is called to let your application know that it moved from
the inactive to active state. This can occur because your application
was launched by the user or the system. Applications can also return
to the active state if the user chooses to ignore an interruption
(such as an incoming phone call or SMS message) that sent the
application temporarily to the inactive state.
You should use this method to restart any tasks that were paused (or
not yet started) while the application was inactive. For example, you
could use it to restart timers or throttle up OpenGL ES frame rates.
If your application was previously in the background, you could also
use it to refresh your application’s user interface.
After calling this method, the application also posts a
UIApplicationDidBecomeActiveNotification notification to give
interested objects a chance to respond to the transition. Availability
When the app is suspended it shouldn't be refreshing. Per Apple's documentation, unless your app has registered for one of the specific background processes, the app is essentially frozen until it resumes. There shouldn't be any network calls made.
However, if you DO want to kill the app once it's been suspended for too long, you could implement a hack that registers a background timer for 10 minutes, then after 10 minutes call some garbage code that you know will crash. Problem solved :)