I'm working on an iPad app, targeting iOS 3.2 (so everyone can run it), and when the user presses the Home button, the app gets an applicationWillTerminate: message and it sends usage data to a server before it exits.
This all works fine. But if you exit and then restart the app before it's done exiting, it appears to crash.
The 5 seconds you get to clean up when the app is exiting begins once you get the applicationWillTerminate: message, but the app disappears immediately from the device, giving the user the opportunity to launch it again.
I think what's happening, is that they're just reactivating the app before it's done exiting, and so they're just jumping back into the first instance of the app just before it actually exits. So the second instance of the app appears to be crashing.
There is no crash log, and putting a log message into the application:didFinishLaunchingWithOptions: doesn't produce any logs in the console from that second launching of the app. This is why I'm pretty sure it's not actually creating a second instance but just re-entering the first instance which is almost done exiting.
So are there any ideas out there about how to avoid this situation? It seems odd that you are given 5 seconds to perform actions on exit, but then this odd behaviour happens as a result.
I'm worried part of the problem is that the app is targeting iOS 3.2 and is actually exiting when the HOME button is pressed, and if it were just going into the background, this wouldn't be an issue. Sadly, changing that behaviour is just not an option at this moment.
Related
I am using Local notification in my application.it is working fine in foreground and background.
Now, What i need,if i remove my app from background then i want to cancel all notification
before that.
so , there are not any method are calling in appdelegate when i am going to remove my app from background, obviously it is going to Suspended state so no method is going to called.
so is there any other way to do this ?
Thanks in advance...
Considering your app is not one of the supported background execution modes, like audio, VoIP, or navigation,
Your app will generally never see willTerminate, because the system generally only terminates your app once it's already suspended (in the background). Once your app is suspended, it gets no further chance to act, so there's no callback for that.
The didEnterBackground delegate message or notification should be considered your last chance to clean things up or save state before possible termination.
Here and here are good overview of the application lifecycle notifications & delegate messages on iOS 4.0 and later.
Does anyone have any insights into when/under what conditions applicationWillTerminate is called in iOS 5/6?
I've got some logic i'd like to execute whenever the application terminates (not moves to the background), for example if the user navigates to the application bar at the bottom of the screen by double tapping the home button and force quits the app.
when i try to do this on a test device, applicationWillTerminate does not seem to get called. Is there a reason for this?
My plan B is to tie that logic to some persistent object like a singleton or a static that is automatically destroyed when the app quits.
Any suggestions?
thanks
Have you read the documentation for applicationWillTerminate:,
It says,
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.
There is a "maybe" mentioned there. Probably that answers your question. So it is not necessary that this will get called when you quit the app. Probably you might have to use UIApplicationExitsOnSuspend to disable multitasking and then it might get called while putting in background. But that again depends on your app requirement. If you cannot disable multitasking, you might have consider doing that in applicationDidEnterBackground method or so. I am not sure if there are any other delegate methods which will help in identifying the force quit.
There is a small bug in my App.
My App displays notifications at specific times when the App is running and cancel all of them whenever a button is switched.
My problem is that whenever a user closes the App using the multitasking feature of iOS the notifications are still showing up.
I tried to add the following code which doesn't work:
- (void)applicationWillTerminate:(UIApplication *)application
{
// Called when the application is about to terminate. Save data if appropriate. See also applicationDidEnterBackground:.
[[UIApplication sharedApplication] cancelAllLocalNotifications];
}
The problem is that my App should show notifications when the App is running but shouldn't show notifications when the App is terminated.
Why does the above code not work?
The correct answer is that this cannot currently be done by a multitasking app. One solution is to set a flag in our info.plist declaring your app wants to be killed when the user switches to another app - then you will get the willTerminate message (but get killed then).
There are huge numbers of threads on this topic, one which quotes an Apple doc that tells you backgrounded apps that are terminated do NOT get the willTerminate message is here.
For me, this just means I can now close an open bugreport out with a 'cannot fix' resolution :-)
Just because your app is visible in the app-changer, it doesn't mean it is still running.. it can get closed at any point. You cannot differentiate between the OS closing your app or the user closing your app.
Perhaps a button would be the solution? A button that cancels all notifications?
Or you run a real background task (which can last for about 5 minutes) and stop all notifications afterwards. Or you just schedule the notifications for the next 5-10 minutes and that's it.
For what are you using them?
Of the many problems I've been having with my current app, this is one of the most annoying.
In the simulator the login dialog works fine, however on a device it's just a frozen white box and the console prints the following:
void SendDelegateMessage(NSInvocation*): delegate
(webView:resource:willSendRequest:redirectResponse:fromDataSource:)
failed to return after waiting 10 seconds. main run loop mode: kCFRunLoopDefaultMode
I've looked this up but I'm still not sure what it means.
If I try switching
[self authorizeWithFBAppAuth:NO safariAuth:NO];
to
[self authorizeWithFBAppAuth:NO safariAuth:YES];
it switches to the safari app to verify but this somehow kills my app with an error which says ReturnNotPermittedKillClient.
Has anyone experienced a similar problem? On my last app it just worked without any of these issues, and as far as I can see I've done everything the same way this time. However this project was inherited from someone else so there may be underlying causes that I am not aware of.
Edit: Just tried moving the login request from didFinishLaunchingWithOptions to a point in the intro screen class where everything else has already been loaded, just in case it was a memory issue caused by too many tasks trying to run at the same time. This time the error message didn't appear, however the login box still remained white and then closed the app a few seconds later.
Edit2: Seems like it's simply a memory error. I changed all variables which I had previously released to be retained, which has fixed the problem on my 3GS. However on my iPad 1 the problem persists. Incidentally, when changing shouldAutorotateToInterfaceOrientation from using landscaperight to using landscaperight or landscapeleft, when I rotate the iPad I get a memory warning and then the same crash. In both cases there are no debug error messages other than the memory warning, and the app just closes down - there is no breakpoint etc to see where the issue lies.
if you are using the webview then we need to do this first b4 moving to next view .delegate = nil;
This might be what you want:
There are other branches of this in NSObject in the documentation.
Code:
[self performSelector: withObject: afterDelay: ]
The problem was simply down to memory. After changing the way it loads images, sounds etc the problem has gone away.
It may sound as a dumb question. In fact, I am still thinking if that might be the cause but working with XCode and having set iOS 4.3 as my Deployment Target and iPad as my Device I am getting an unexpected error.
While running my app through the Simulator I can get it working. But when I run it through my iPad a single IBAction, fired when user taps an UIButton, that takes almost 4 minutes is not completing. In fact it's getting stopped at the same point, in a for loop.
I searched for memory leaks using XCode and it didn't find any, therefore I'm asking if there's a time limit for IBActions. I read there are 10 minutes limit for methods in background but I didn't find anything related to IBActions in foreground yet.
I think the user gets tired of waiting for a response long before the system. Normally, a button press or similar should finish after one second at most (well, maybe 1.5s), or the user thinks that the system is "slow".
I would make sure that you have your button outlets properly hooked up. It is possible that it just isn't throwing the exception so you get a slow system. Put NSLog displays in your IBAction method and make sure it is executing it properly. You should be able to track it back to figure out what is going on.