Hee
Does anybody know how to recognize a multitask-kill.
When the user puts the application in background state and then kills the app through the menu in iOS 4.2 my application shuts down.
Before there used to be an function called:
- (void)applicationWillTerminate:(UIApplication *)application
This method is not called anymore in iOS 4 and higher.
Is there a way to recognize it?
Thanks already.
Actually that's not entirely true. It is called on iOS4 devices that do not support multi-tasking and the documentation says that it can be called on other handsets (though I've never seen it myself).
But to answer your question, no, you can't recognise when a user kills your app. If you have state that you want to save you need to do this when your app goes into the background and not when the app is killed.
If you look at the crash reports you'll see that iOS sends SIGKIL which you can't catch.
You cannot catch this, your processed really is killed. Hard. Without notice. That us why you need to save state when you enter background now.
Maybe setting up a signal handler might work (don't know which signal to catch, though).
Related
I'm new to swift and programming so I'm not sure if or how this is possible, but could anyone tell me if I can designate code to be executed when the user terminates the app from the multitasking menu? I just have a line of code that I would like to execute at that time, but I'm not sure where to put it in my project.
Thanks!
If the user terminates the app from the multitasking menu, your app is killed dead. It is not terminated "in good order". You do not get an event at that time. It's just like the scene in 2001: A Space Odyssey where the scientists are already in suspended animation and HAL pulls the plug on them.
The art of Cocoa / iOS 8 programming is the art of the possible. Adjust your desires to fit the reality of the events you do get. You get an event when the user leaves your app, so if there is something you need to be sure to do, do it then, as you may never get another chance.
As matt said, when the app is terminated from the multitasking menu, none of your code is run, it's just killed.
Try putting your code into the application delegate's applicationWillResignActive(_:) method. This will run any time your app becomes inactive, though. In other words, more often (all the time) than being terminated in the multitasking menu. It'll run when there's an incoming phone call or text, I believe it will run if there is a notification with an alert, it will run when the user presses the home button.
My app has to run for a long time (also) in the background, due to Location Services.
When a certain condition is met the app has to move to the foreground.
I was able to run my app in the background and bring it to the front manually.
Reading up on this issue I got confused on how to move my app to the foreground by code.
It has to be in an if statement but what to do from here?
No do not think this is possible. You will be able to spawn a UILocalNotification to show application state to the user, but it is my understanding that iOS prevents you from making your app take focus.
you can't do that without user interaction. You can present a UILocalNotification
-- you can't even be sure iOS leaves it running though!
on a jailbroken phone I guess it is possible
This is clearly not possible, as it would be a mess if any app could just take over control at any point in time. As mentioned, you have to post a notification, and then it is up to the user if he or she wants to launch the app. If you notification states a good reason why they should launch your app, they might very well do it :-) And remember, don't mix up the user's needs with your/your app's needs.
Does anyone know how to detect if the user has force killed my app while the app is in the background? In the Apple documentation for the applicationWillTerminate: method it says this:
"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."
From my testing, when I force kill the app, my app still looks like it is tracking my location (the arrow is still at the top). But the cllocationmanager delegate method is not getting called until the app is relaunched, and the manager is stopped then started again. What is the best way, if any, to handle this situation?
Thanks!
UPDATE:
After looking into this post: Behaviour for significant change location API when terminated/suspended?
I'm still left with a problem. Because I'm using the method startUpdatingLocation, rather than the startMonitoringSignificantLocationChanges method. It looks like the application is only relaunched if you are logging significant changes. It seems to me that's it's kinda a hack to log significant changes just so I don't lose the app. Any ideas?
I'm setting "Application does not run in background" to NO
which means, it can go background and resumed later.
I'm putting some code in "applicationDidEnterBackground",
and I would like to force quit the app when desirable. (when there's nothing to do in background.)
I read 'exit' is not recommended.
Can I post a message which will result in something like applicationWillTerminate maybe?
Edit
Let me clarify why I would want that,
I want my app to run background when it's downloading something.. via beginBackgroundTaskWithExpirationHandler
But if user isn't downloading anything, I can safely quit the application.
Thank you
The general Apple approach on iOS is that applications should never terminate themselves, for any reason.
It's important to understand that when your application is 'running' in the background, it's not really running: the 'Application does not run in background' key is basically there to ensure backwards compatibility with applications built for iOS 3 and lower, which tend to make certain assumptions about how the user will enter the app. There are very few reasons why a new app wouldn't support it.
Basically, don't bother: I suppose you could technically call exit(), but Apple will hate you for it, and it's bad style for the platform.
You don't need to worry about this.
If you have work to do in the background and you set up a background task then it'll run for as long as it needs and execute its handler when done.
What you don't seem to be aware of is that if you have nothing to do in the background, your app is simply suspended and in fact does not run.
As this is the case, there's nothing you need to do, quitting the app won't gain you anything that you don't already get with suspension.
I am running my iPod touch application and then go in background and change the device language from Settings application and try to bring that application on foreground. My application gets restarted and I do not land on the screen where I left the application when I went into the background.
Is this because a KILL signal is sent by settings application when language was changed? Is it the desired behavior?
I wasn't aware the switching the language would cause apps to be terminated, but that's not shocking. It's a very straightforward way to get what the user wants. Your problem isn't the language change, though. The problem is that you're not responding correctly to a notification of termination. You can be terminated at any time when you're in the background, and it's your job to deal with it.
Your application delegate should implement applicationWillTerminate: (or you can observe UIApplicationWillTerminateNotification wherever it is convenient). When you receive this, you should save off sufficient information to get yourself back to where you were when you restart. As much as possible, you should make it look to the user that you did not terminate. The easiest place to save state is usually in NSUserDefaults, but you can use any mechanism you like.
Handling application restart is one of those things that separates excellent iOS applications from "good enough."