Skip to main content

Deals You Can't Miss

1 Year Subscription

Android Activity's onDestroy() Ain't Your Reliable Friend



Look at the Android Activity life-cycle events in the picture beside.

The lifecycle isn't something new. You're familiar with it right? You're also that good Android developer that writes clean code, wherein you consciously override onDestroy() method to include resources clean-up code and save some state, right?

Per Android doc, it is okay and usually the practice to write cleanup code in this method but not anything beyond that.

So if you are to write code to persist state in this method, or anything else beyond resource clean-up (like threads associated with an activity), you're better off to push it up the life-cycle, either in onStop() or onPause() method.

That is how I settled in the first iteration of new learning but wasn't happy. Why? To quote Android Doc:

There are situations where the system will simply kill the activity's hosting process without calling this onDestroy() 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.
What are those other methods that aren't guaranteed to be called? So is my learnings in the first iteration right? I'm really thirsty to know the right way of doing things - "what fits where?".

And then this SO thread and Android Doc - Activity, quenched my thirst to come up with the following points in learning:
1. In pre-Honeycomb versions of Android onPause(), onStop() and onDestroy() are all potential-killer methods in that when these methods gets executed and returns, the process hosting the activity may be killed by the system at any time without another line of its code being executed. Thus there is no guarantee that onStop() and onDestroy() will be called.
2. In post-Honeycomb versions of Android onStop() and onDestroy() are both potential-killer methods. Thus there is no guarantee that onDestroy() will be called.
3. onDestroy() will not be called only if the process hosting the entire application is killed. When the process is killed, all resources allocated to it are freed, therefore there is no risk of memory leak in this case.

Based on these new lessons that we just learned, we arrive at the following practices:
1. Use the onPause() or onSaveInstanceState(Bundle) method to write any persistent data (such as user edits) to storage.
2. Given that there is no risk of memory leak even if onDestroy() method is not called, it might seem okay to write resource clean-up code here. But don't. Prefer to write clean-up code in the onStop() method.
3. As you put this learning into practice, ensure the sanity of creation/destruction goes in onStart()/onStop() or onResume()/onPause() pairs. Don't mix and match, lest your app's users might see weird app behaviours.


Additional Reading

When an Activity goes to background it is stopped, but not destroyed (usually). Activity can remain in this "stopped" state for quite a long time, and will be started again if the user returns to the application. If you release resources in onDestroy() method, which is not called when that Activity goes to background, the Activity will continue to hold to its resources in that stopped state, thus causing higher amount of OS resources to be consumed by your app in background state.

When Android runs out of memory, it starts killing the processes in order to free the memory consumed by them. One of the most important considerations taken into account when choosing which processes to kill is their resource consumption and the app state. Thus, if your app holds to resources while in background (stopped state), it likely calls for the attention of Android OS to kill it.

Great developers strive to make the best apps for end-users. App that consumes unwarranted amount of user phone's resources while in background is not a good application. Weather or not the users know about it, Google Play gets to know it, affecting the app's ranking in the play store.

Therefore, let's write clean-up code in onStop() method. Let's avoid overwriting onDestroy() methods in Activities, Fragments, et. all.


References

1. Android doc - Activity Lifecycle - onDestroy() section
2. SO - Release resources in onPause instead of onDestroy
3. Android onStop/onDestroy - when might these be used?
4. Android doc - Activity Lifecycle - See killable column of the table

My Popular Posts

Ten Commandments of Egoless Programming

We are nothing but the values we carry. All through my life thus far, I tried to influence people around me with the virtues I value. Thanks to some good reading habits I had inculcated, and the fortune of being in good community of peers and mentors alike, I managed to have read some real good books. This post is about the 10 commands of egoless programming in Weinberg's book. I shall explain the commandments based on my experience here. So very many decades ago, Gerald M. Weinberg authored  The Psychology of Computer Programming . In it, he listed The Ten Commandments of  Egoless Programming , which remains relevant even today for us as not just programmers but as team-members. Weinberg is regarded as a pioneer in taking a people-centric approach to computing, and his work endures as a good guide to intelligence, skill, teamwork, and problem-solving power of a developer. When they appear to inspire and instruct, we find that they can apply to just about every business area, and e

Should I buy refurbished laptop from Amazon?

This post is based on my experience with amazon.in and guess it to be true on all other platforms as well. At least you can check out and verify for these pointers before you make that decision to buy renewed/refurbished laptop on Amazon with your hard earned money. I see this question propping up in several forums and on many different occasions. In the recent past, I had my 5 year old dell laptop that gave up because its motherboard failed. One of the options that I had in my mind was to re-use the HDD and the 16GB DDR4 RAM of that old laptop in the one that I purchase next as secondary.  I had come to a conclusion that it is not worth buying a refurbished/renewed laptop at all. Why? For the following reasons, most of which I see as BIG #RedFlags: You got to remember that Amazon provides a platform for 3rd party sellers to sell their products as well. So in your search for refurbished laptops you wouldn’t want to choose some random 3rd party seller who Amazon doesn’t endorse. You cou

Multi-tenant Architectures

  Multi-tenancy Application Deployment Architecture could be modeled in 4 broad ways: Separate Apps & Separate Databases Shared Apps & Shared Databases Separate Apps & Shared Databases Shared Apps & Separate Databases There is no right or wrong here. It's about choice and consequence that you should consider taking into your business context and constraints. In this post I intend to jot down a some key points to keep in mind for each of these multi-tenant architecture. These are more of quick notes for my quick reference, a cheat-sheet of sorts when I have to make choices. And I guess this can come handy to you too in your wise decision making. Separate Apps & Separate Databases Easiest to implement from development and deployment stand-point. Just automate the deployment infrastructure for every tenant for quick set-up. Most expensive of all the models from infrastructure cost stand-point. Relatively longer deployment t