iOS how to detect when app was removed from process - ios

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

Fetch location when user forcefully quit the application in iOS

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 iOS app delegate methods does the springboard kill trigger? [duplicate]

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 call back method for killing the application instance?

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

How to ensure iOS app doesn't remain suspended in the background indefinitely?

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 :)

Sending Application to background on iphone

Is it possible to send the application to background programmatically on iPhone?
Under iOS 4.0, your app will be put in the background if another app enters the foreground, and there are enough resources to keep your app in the background. You could send a URL to Safari, or another app that has registered for a handler, and hope that there's enough memory (etc.) that the OS puts your app in the background after it starts Safari (or whatever app handled the URL). If you are lucky (which typically happens fairly often), you will have sent your app programmatically to the background.
Of course, whether your app runs in the background, or is just suspended, depends on other things (which you have to register with iOS 4.x for).
Apple does allow apps to exit (kill themselves) programmatically. But it's meant only as a last resort for when something bad happens from which your app cannot recover.
On all other occasions, apps are expected to stay in the foreground and running until either the user presses the home button or the app opens another app, with the users consent.
Actually you don't want to kill the app, however moving it to the background and returning to the home screen would leave a very similar impression. That's why I don't think Apple would approve it and consequently doesn't offer, as far as I know, any means to move an app to the background programmatically without opening another app.
No it is not possible. Only iOS can put your application in the background.
Note that there's a lot of confusion between "background" and "inactive". An inactive application is one that is not displayed on the GUI but is still running.
Technically an application in the background isn't running; it's dormant. Depending on the mode used, a background applications can receive signals and "wake up." See Background Modes for more details: https://developer.apple.com/library/ios/documentation/general/Reference/InfoPlistKeyReference/Articles/iPhoneOSKeys.html#//apple_ref/doc/uid/TP40009252-SW22
But a background application can also get terminated at any point without warning. As a matter of fact I always treat a background application as terminated. Therefore you should always clean up your application before you enter the background, and re-initialize it when you enter the foreground.
This is a must-read on this topic: https://developer.apple.com/library/ios/documentation/iphone/conceptual/iphoneosprogrammingguide/ManagingYourApplicationsFlow/ManagingYourApplicationsFlow.html
check out these post
local notifications?
iPhone - Backgrounding to poll for events

Resources