Guaranteed alternative to onDestroy()?

Question

I'm trying to execute some code whenever my activity is killed, but not when it's simply moved to the background (so just calling it in onPause() isn't a solution), and I understand onDestory() is not guaranteed to be called. I've been searching all over and haven't found a way to do this. How can I go about tackling this problem? Is it possible?

Outbid

I understand onDestory() is not guaranteed to be called. where did you get that from? – Pagano

"There are situations where the system will simply kill the activity's hosting process without calling this method (or any others) in it, so it should not be used to do things that are intended to remain around after the process goes away." developer.android.com/reference/android/app/… – Outbid

Have you tried putting the code in onDestroy() and seeing what happens? – Kinsey

@AmandaS Yes, I've tried manually exiting the app (swiping/removing it from the recent apps list, and a file on the system that should have been deleted (from my onDestroy() method) remained. – Outbid

sweeping from recents just sweeps from recents. you exit nothing – Roomer

@AmandaS - bad idea - experiment does not lead to a guarantee, and this is a subject where it is already well known that there is no guarantee which can be made. – Freer

without calling this method (or any others) doesn't sound like what you look for exists. – Pagano

Answer 1

Nothing. You can never be guarantied to be called when an app ends, because it can always be terminated abnormally- it could crash, the battery could be pulled out, etc. onDestroy is the closest you can come. But you should never write a program that requires cleanup at termination time.

Jezabel

Hmm. Well I have a temp file created by my activity that should be deleted if it still exists when my app is exited. How else would I ensure that? – Outbid

@JoshBjelovuk - you don't. Clean it up on the next run to avoid storage growth. If you are worried about information leakage, then you shouldn't be writing that information out anyway, since the file would be there while the activity is open. – Freer

Guess I better start rethinking my approach. Thanks for the feedback. – Outbid

Answer 2

I'm not sure, but I suspect you've got a few issues which you've conflated into one large issue;

As I read this question you have 2 or 3 concerns:

1) You want to garuntee something happens when the app exits.

2) You have state you want to maintain during onPause() but not after onDestroy()

3) You presumably have some content which should not persist between application usages.

Some answers:

1) As Gabe points out - there is no guarantee anything will ever be called. I can pop the back off the device and pull out the battery. Your calls aren't going to happen.

2) You might try onDestroyView() for this case. It won't be called in many circumstances in which onPause will be (for example when an alert dialog is shown), but will be called in others (when you replace a fragment with another fragment for example).

3) This issue makes me think you may want to reconsider your method of storing/saving this information. If you don't want it to exist on the system when you app isn't in use, it is best to never write the data to the filesystem. (Due to 1). Other options are keeping it in memory. You could also use shared preferences/preferences mechanism but this will still exist on the filesystem until your app is removed.

Vanderhoek