Reputation: 70733
Suppose I have an iOS app that is actually running in the background (for one of several legal reasons, such as background audio, requested time, etc.). What things might cause the OS to close (kill) this app instead of just running or suspending it? How can I avoid them? How can I reliably trigger them (within this app) using public APIs?
Upvotes: 1
Views: 450
Reputation: 94834
Your app might be killed if it uses too much memory, if it does not call endBackgroundTask:
when the expiration handler (specified when calling beginBackgroundTaskWithExpirationHandler:
) is called, if the user explicitly kills it, if the app throws an exception, calls exit
, triggers an EXC_BAD_ACCESS or other signal, and so on. There are probably other reasons, too.
To avoid these, don't use too much memory, call endBackgroundTask:
when required, make an app that users won't want to kill, and don't throw exceptions, call exit
, access invalid memory locations, and so on.
There isn't a way to reliably trigger "user explicitly kills the app". For the others, you could allocate tons of memory, refuse to call endBackgroundTask:
, use [NSException raise:... format:...]
, call exit
, or create random garbage pointers and follow them. You probably shouldn't actually do any of these, though.
Upvotes: 3
Reputation: 54445
I'm not sure what you're asking - it sounds like you want to be able to terminate other applications, which (thankfully) simply isn't possible on the iOS platform due to sandboxing, etc.
However, the most likely reason your own application will be killed whilst it's running in the background is if it's using a large amount of memory, etc. and doesn't respond to the didReceiveMemoryWarning
calls by shedding resources that are no longer required.
In terms of automatically triggering these, the simplest way would be to use the "Simulate memory warning" option within the "Hardware" menu on the simulator.
Upvotes: 0