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
Related
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.
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.
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 :)
Is applicationDidEnterBackground ALWAYS called before applicationWillTerminate in an iOS app? I know that applicationWillTerminate is not always called (multitasking) - but when it is called, is applicationDidEnterBackground ALWAYS called first? I don't want to duplicate code unnecessarily by including it in applicationWillTerminate if it is already included in applicationDidEnterBackground, for an app that supports multitasking.
in ios 4.0 and later applicationDidEnterBackground is called instead of applicationWillTerminate so you don't have to call both of them. Here is the portion of the Apple docs:
Discussion
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 perform any tasks relating to adjusting your user interface
before this method exits but other tasks (such as saving state) should
be moved to a concurrent dispatch queue or secondary thread as needed.
Because it's likely any background tasks you start in
applicationDidEnterBackground: will not run until after that method
exits, you should request additional background execution time before
starting those tasks. In other words, first call
beginBackgroundTaskWithExpirationHandler: and then run the task on a
dispatch queue or secondary thread.
The application also posts a
UIApplicationDidEnterBackgroundNotification notification around the
same time it calls this method to give interested objects a chance to
respond to the transition.
For more information about how to transition gracefully to the
background, and for information about how to start background tasks at
quit time, see iOS App Programming Guide.
Hope this helps clear the issue for you man.
Adrian
Here is the link to the technical note that is available on developer section. It is dealing with networking and multitasking. The actual method used in this doc deals with only applicationDidEnterBackground and since iOS 5 they have a system called watchdog which terminates the app if the network is unresponsive automatically. Hence there is no need to actually call applicationWillTerminate and try to execute codes to allow your app to finish its task before the app is terminated. The app will enter the background and will continue its task until the last task is completed. I hope that makes sense, but here is the link. Please read the watchdog section.
https://developer.apple.com/library/ios/#technotes/tn2277/_index.html#//apple_ref/doc/uid/DTS40010841
Hope this helps. :)