currently I am testing AppDelegate methods, when they are executed by adding NSLog to every method. What is not clear to me is when method applicationWillTerminate is executed? I've tried to put app in background, then to terminate it, but log from Terminate method is not executed. What is executed is this:
2015-09-01 16:24:01.512 TestQuestions[2351:110179] didFinisLaunching
2015-09-01 16:24:02.530 TestQuestions[2351:110179] didBecomeActive
2015-09-01 16:24:05.864 TestQuestions[2351:110179] willResign
2015-09-01 16:24:06.322 TestQuestions[2351:110179] didEnterBackground
What is not clear to me is when method applicationWillTerminate is executed
Almost never. It can be called under certain rare circumstances where you are e.g. playing music in the background and are terminated from there. But in general you should expect that it will never be called, because by the time you are terminated, you are already suspended and your code is no longer running (and the system is not going to wake you up just to tell you it's killing you in the background).
One time that applicationWillTerminate will execute is when a user touches (once or twice) the Home button and then slides the app off the screen.
Personally I do this regularly since I touch the Home button to switch between regularly used apps that I want to make active, rather that finding them in my 9 pages of icons.
Related
I've been using interactive notification and it works well when my app is suspended in the background, but causes problems when my app has been terminated.
I've used NSLog to determine the app's lifecycle when the interactive notification is triggered when the app has not launched.
The following goes on, in the order listed, without the app visibly launching:
didfinishlaunching
handleActionWithIdentifier
viewdidload
viewwilllayoutsubviews
viewdidlayoutsubviews
viewdidappear
The app then seems to terminate without calling
didenterbackground or willTerminate
The reason why it's causing issues for me is because I create timers in viewdidload that are invalidated in didenterbackground.
Because didenterbackground isn't being called, when the app is subsequently launched after triggering an interactive notification I'm ending up with two instances of the timer.
Could anyone shed some light on why the app terminates but didenterbackground or willTerminate aren't being called?
You should not assume that a call to didfinishlaunching means that you are in the foreground. As #PaulW11 says in his comment, for local notifications when your app is not running, you get launched directly into the background, and never see a foreground-to-background transition, because you were never in the foreground in the first place.
The system will call applicationDidBecomeActive: if you are being launched into the foreground. You should put your code that starts your timers there.
The docs say that local notification notices get invoked in the background:
When the user taps a custom action in the alert for a remote or local
notification’s, the system calls the
application:handleActionWithIdentifier:forRemoteNotification:completionHandler:
or
application:handleActionWithIdentifier:forLocalNotification:completionHandler:
method in the background so that your app can perform the associated
action.
You should write your application:handleActionWithIdentifier:forLocalNotification:completionHandler: method to check to see if it's being called from the foreground or from the background.
I use (Objective-C) code like this to tell if I'm in the foreground or the background:
BOOL inBackground = [UIApplication sharedApplication].applicationState == UIApplicationStateBackground;
I started a timer when app goes into background when selector method called app got crashed in background. I am not sure does code works in defined conditions.
In background mode, when your app is not running, timers will just not fire. A timer will fire at the earliest time it can (for example just after your app is activated again). If a repeating timer should have fired more than once, only the last "fire" will happen.
This shouldn't make your app crash; whatever goes wrong is something else.
Timers only run in the background if you app supports running in the background, like when tracking location, playing music, etc.
I'm having an issue where my app is crashing on sleep, and sometimes on home. I'm getting a BAD_ACCESS error in a thread called gpus_ReturnNotPermittedKillClient, which tells me that my app is making UI changes in the background, which to my understanding is a no-go. Therefore, I'm stepping through my code to see what happens on home / sleep, and I find that my breakpoint in my VC's -viewWillLayoutSubviews method is getting hit AFTER the breakpoints in the -applicationWillResignActive and -appplicationDidEnterBackground notifications (in which I'm attempting to stop all updates from an asynchronous callback function).
That doesn't seem to make any sense. From the application's perspective, if it's not cool to do UI updates in the background, why call viewWillLayoutSubviews after you're in the background?
EDIT: It appears to do this even when my app doesn't crash. Could it just be lldb getting things out of order?
I think you simply need to be tolerant of this. Per this tech note, you can't do any GLES rendering in the background. My recommendation would be for your app to set a flag when applicationWillResignActive is called, and then before doing any rendering work you check that flag and don't do the work (and perhaps just call -setNeedsDisplay on the view so that if your app becomes active again it will know to draw that view). You seem troubled by the fact that viewWillLayoutSubviews is getting called "late", but I don't see how that really matters. (i.e. layout != rendering) I would be surprised if your view's -drawRect: method were getting called after applicationDidEnterBackground but I would still say that it would be your responsibility to check a flag and not render if your app is in the background.
I am currently developing an app that will need to terminate after running in the background for more than five minutes. In order to do this, I will have to have a timer running in the background after the the Home button has been pressed or in case of an interruptions such as an SMS or a telephone call, then, after five minutes the applicationWillTerminate method will be called. My first question is should I put the applicationWillTerminate in the applicationWillResignActive method or in the applicationDidEnterBackground method? My second question is since this is an app with more that one view, Should I write these things in the AppDelegate class or elsewhere? Thank you for your response.
1) You can't force your app to finish programatically.
2) You should never call these AppDelegate methods by yourself. They're meant to be called only by the system.
Reference: UIApplicationDelegate Protocol Reference.
This is pretty ghetto, but what you can do is make your app crash when you want it to exit, and it will close automatically, granted that's not closing the app, but there's no real harm in it as long as you are in control of how it crashes try to go for a bad access error, aka trying to access something that has been deallocated
as for running a timer in the background, i don't know per say if you can do that, but as an alternative you can save the time when they leave the app aka the app goes into the background and then you can have all the events return to your app of the view controller that is first responder, and each UIEvent has a time stamp, and regardless of which event it is you can compare the time stamps and see if it's greater than 5 minutes
Regardless i don't suggest any of the above, but that is the best answer i can come up with for your question
the code for receiving events out side of your app
[[UIApplication sharedApplication] beginReceivingRemoteControlEvents];
will start the event tracking and the call back is:
- (void)remoteControlReceivedWithEvent:(UIEvent *)event { }
but you have to remember to
[self becomeFirstResponder];
this tells the device which view controller to go to for the event tracking, oh and don't forget to resign first responder, and endReceivingRemotecontrolEvents
I am scheduling a selector using performSelector:withObject:afterDelay: with a five minute delay. If the device goes to sleep for more than five minutes while this is scheduled, then one of two things happens:
1) If the device is connected to my laptop, and the app is running in the debugger, then when the app wakes back up the selector fires immediately. It seems like the "clock keeps running" for the delay.
2) If the device is not connected, then there is a delay before the selector fires. It seems like the "clock pauses" for the delayed selector.
It seems strange that there would be two different behaviors depending on whether the device is connected to the debugger or not. Any ideas?
I've noticed that the debugger seems to force the app alive in the background.
Typically, if you are debugging on a real device and press the home button, nothing special will happen, even after 10 minutes.
On the other hand, if you force kill your app on the device, you'll end up receiving a SIGKILL signal which will terminate your debug session.
The app is paused, when in background. You should generally save timers etc, in applicationDidEnterBackground and restart them in applicationDidBecomeActive.