I m facing big problem With Application Termination State.In My app
need to Satisfied Following Points.....
1)Application Is in Back Ground Switch To Fore Ground (no Need To
Store Data)
2)Application Is Background After Some Time If User Go to home And
Terminate Application (need To Store Data)
is there any delegate method Will Call Before Application
Terminate . - (void)applicationWillTerminate:(UIApplication
*)application
Is not Working With Because In 1 Case Application Running So
Suspended When We Try to Terminate Application.
Please Help me Out From This Issue..... If Any Ideas Also Would Be
Appropriated
You should always store your data when going into the background (applicationDidEnterBackground:). There is no guarantee that you will receive any further opportunities prior to being terminated.
This is how it's supposed to work. This is what it says in the documentation:
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
If there is data that you need to save, you should do it when the app goes into the background.
No there is nothing called, because your app killed by the OS, this could also happen if the system need more free memory.
You should save the data when every your app gets send to the background, not when it gets terminated.
Related
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.
So here is the issue I am facing. Certain portions of the application I am building open some c network sockets that allow connections to various servers/services. However, if the application goes to sleep, these socket connections are lost, and error out when trying to reload them. So what I want to do is basically notify the user when the app launches again, that the application needs to be restarted. The main question is, can I present them with a button that will kill the app by using exit(0) without my app getting rejected?
Apple says that the user should be in control of when the app is killed, and in this case I see that they are, but I am not sure of Apple's opinion on this. Has anyone else used this? Have you been rejected for this? Thanks in advance for any advice!
EDIT:
Thank you everyone for your advice. I am trying to take everything into consideration, but because the app needs to be submitted ASAP, I just need to know, if we can not get another solution, if the above proposed solution, will get rejected or not.
Your application delegate receives notifications when significant events affect the life of the application. Rather than ask your user to recreate a session, you should attempt to discontinue network operations and then resume them at the appropriate times in the application's lifecycle automatically.
You can gracefully kill network sockets (amongst other things) in any number of places as the application prepares to exit or enter the background via callbacks in your application delegate:
applicationWillResignActive:
applicationWillEnterBackground:
applicationWillTerminate:
Potentially reconstruct sockets in:
applicationDidBecomeActive
applicationWillEnterForeground
Have you tried not allowing the app to run in the background? Then it will be killed whenever the user exits to the home screen. This might be a bit aggressive, but would solve the problem. From Apple's opting out of background execution:
"If you do not want your application to remain in the background when
it is quit, you can explicitly opt out of the background execution
model by adding the UIApplicationExitsOnSuspend key to your
application’s Info.plist file and setting its value to YES.
When an application opts out, it cycles between the not running,
inactive, and active states and never enters the background or
suspended states.
When the user taps the Home button to quit the application, the
applicationWillTerminate: method of the application delegate is called
and the application has approximately five seconds to clean up and
exit before it is terminated and moved back to the not running state."
See also: How to prevent my app from running in the background on the iPhone
The documentation is pretty explicit about this, "There is no API provided for gracefully terminating an iOS application." See Technical Q&A QA1561
How do I programmatically quit my iOS application?.
To be blunt, terminating an app to cleanup a socket is just like dealing with memory management by forcing an app to exit instead of calling release.
What about bringing up a modal view controller telling the user to quit the application? You could make this view controller without any dismiss button, so the user is obligated to kill the app.
As in my application if some action regarding "httpcall" are posted in the mainthread and my app is waiting for a response from server and same time home button is pressed than although app is entering background but IOS delegates (such as "didEnterBackground") are not getting called till the response are received.
Also sometime even if I'm relaunching the app its not responding till it gets crashed by itself.
Note:I'm using CyberLink code for my HTTP posts.
As Apple says :
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)
I think you try to do something in background, for which didEnterBackground is not enough. Use Grand Central Dispach istead.
Since your Http method are of synchronous type ..Your UI will froze till response.
What you have done is in simple words tell the OS to perform these http requests before doing anything else.
On pressing home the system will wait..for a few seconds to receive a response..otherwise it will quit thee app. since it violates app guidelines..(you are blocking OS indefinitely)
The didEnterBackground will be called only if these requests will be finished or will not be called in the case when OS decides to terminate your app.
When my application is moved into the background, I'd like to be able to detect when it is about to be terminated (for memory exhaustion or other reasons). Is there a way to do this?
In particular, is there a way to execute some code before the application is terminated when in the background?
You can do this in the -[<UIApplicationDelegate> applicationWillTerminate:] method of your application delegate, like this:
- (void)applicationWillTerminate:(UIApplication *)application {
[database save]; // or whatever you want to do
}
This will be executed whenever the app is about to be terminated, unless it crashes.
Your best bet is to do whatever cleanup needs to be done in your application (saving state or user data, etc.) as your application transitions into the background. If your application is suspended, you will not have a chance to perform any last code before it is terminated by the system.
From the iOS Application Programming Guide:
If your application is running (either
in the foreground or background) at
termination time, the system calls
your application delegate’s
applicationWillTerminate: method so
that you can perform any required
cleanup. You can use this method to
save user data or application state
information that you would use to
restore your application to its
current state on a subsequent launch.
Your method implementation has
approximately 5 seconds to perform any
tasks and return. If it does not
return in time, the application is
killed and removed from memory. The
applicationWillTerminate: method is
not called if your application is
currently suspended.
Even if you develop your application
using iOS SDK 4 and later, you must
still be prepared for your application
to be killed without any notification.
The user can kill applications
explicitly using the multitasking UI.
In addition, if memory becomes
constrained, the system might remove
applications from memory to make more
room. If your application is currently
suspended, the system kills your
application and removes it from memory
without any notice. However, if your
application is currently running in
the background state (in other words,
not suspended), the system calls the
applicationWillTerminate: method of
your application delegate. Your
application cannot request additional
background execution time from this
method.
It depends.
If you mean getting notification while your application is suspended in the background, there is no way to know; the applicationWillTerminate: method is not run if you're suspended. The recommended approach is to save any required state when you get the applicationWillEnterBackground: message, so that if you get killed in the background you're ready to start up again.
If you're actually in an "executing in the background" state, (which can happen briefly after exiting the app or if the app has requested temporary background execution time,) then applicationWillTerminate: will be called just like you'd expect.
I'm considering how to make my iPhone application as "bullet proof" as possible.
Right now, I'm thinking about how the app will respond to the user hitting the home button at a critical point in the application's processing.
What exactly happens? Are any more instructions executed in the application's threads?
When applicationWillTerminate gets called, I've read that the application "has a few seconds before the os kills the process" - again, what exactly happens?
What I've observed is that the home screen appears immediately, but the app is allowed to continue running in the background for at least a few seconds. If it takes too long, it will get killed.
applicationWillTerminate is called when your application exits due to a call a user decides to take or when the OS kills it due to some other reason. You cannot stop the app from being terminated but can store some data which you want to use later in this method.
For instance if your app lets the user search for something, you can save the search term when the app is about to terminate (in applicationWillTerminate) method so you can use it later when the user logs in to the app again.
So the implementation of the method depends on what you want your app to do when the user decides to quit the app or the OS kills it.
I hear you get about 4.8 seconds to do processing from when applicationWillTerminate gets called otherwise it gets killed. Basically save anything you need quickly!