50

According to the android Activity Lifecycle, the only callback guaranteed to be called (if an activity ever leaves the Running state, which is typically expected) is onPause().

So, I must assume that there are scenarios in which it makes sense to implement onStop() and onDestroy() although they are not really guaranteed to be called.

I understand that onStop() should be implemented when it's possible for an activity to return to the Running state via the Stopped state (why would it do that instead of returning directly is a different question).

But the need for onDestroy(), when I can place all cleanup/state-saving into onPause(), is unclear to me.

Can you describe a real-app situation (i.e. not analogy to driving a car etc.) in which it would make sense to implement onDestroy()?

uTubeFan
  • 6,664
  • 12
  • 41
  • 65
  • Because under normal circumstances, onDestroy() will be called. It's only that it's not _guaranteed_ to be called. For example, if your process gets killed by the oom killer. – Falmarri May 24 '11 at 21:53
  • 2
    @Falmarri But a well written app should be designed for worst case scenario. Are you implying performance improvement under normal circumstances? – uTubeFan May 24 '11 at 21:56
  • Why are you using that diagram (2008!?) instead of the [official one](http://developer.android.com/images/activity_lifecycle.png)? This is one thing that has changed quite a bit since 1.5 . – dmon May 25 '11 at 02:05
  • I'm not implying anything. Just making the note that under the NORMAL lifecycle it will be called and you can use it as part of your expected logic flow. But as you said, you should ALSO gracefully handle worst case. That doesn't mean you should code SOLELY for worst case scenarios. – Falmarri May 27 '11 at 20:41

2 Answers2

26

onDestroy will be called if you explicitly call finish(); yourself.

Your main activity calls startActivityForResult on a map activity.

Map activity with a LocationListener, the user clicks the map and selects say a local restaurant.

The activity then , sets up some extras to be sent back to your main activity, it then explicitly call's finish(); on itself and in the onDestroy kills the LocationListener and other variables you had invoked.

Just found this in the docs

onDestroy() = The final call you receive before your activity is destroyed. This can happen either because the activity is finishing (someone called finish() on it, or because the system is temporarily destroying this instance of the activity to save space. You can distinguish between these two scenarios with the isFinishing() method.

Blundell
  • 75,855
  • 30
  • 208
  • 233
  • 1
    +1 for pointing this out. Does this mean that if I never call `finish()`, `onDestroy()` can be not implemented? – uTubeFan May 24 '11 at 21:54
  • You can implement it. onDestroy will be called at other points (when your app is in the background and is getting killed by the OS). – Blundell May 24 '11 at 21:55
  • 1
    as @Poldie states onDestroy is also called when your activity is killed and recreated (when your activity goes from portrait to landscape on the phone being moved). – Blundell May 24 '11 at 21:59
  • +1 again for explaining what @Poldie wrote (I didn't initially understand that "capture" means "act upon"). – uTubeFan May 24 '11 at 22:53
  • 5
    This makes sense, but does not answer entirely. I can see the cases when onDestroy can be used, but what do we do with the rest? In the given example, what will happen if the activity is killed and onDestroy is not called... it looks like the LocationListener will not be destroyed because we rely on onDestroy for doing that. Even better example: I have an AsyncTask that is running in an Activity. It downloads images. I cancel it in onDestroy (because onStop is not appropriate, it will be called whenever the app is minimized). So what if the Activity is "killed"? Will the task continue running? – Stan Jan 29 '13 at 09:37
  • If you call `finish()` onDestroy is *guaranteed* to be called. If your Activity goes into `onPause` because of other navigation or Android changes (phone call etc) then `onDestroy` possibly won't be called so I would clean up in `onPause` – Blundell Jan 29 '13 at 10:58
  • 3
    This is not the answer to question. OP actually asked why use `onDestory` if can use `isFinishing()` inside `onPause` ? – xmen Jan 26 '14 at 15:31
  • If I'm not calling finish() myself, what else might call it? – Michael Dec 16 '16 at 01:17
  • @Michael if the system is running low on resources (but not so low that it needs rapid clean up) it will call your onDestroy – Blundell Dec 17 '16 at 21:24
  • @Blundell, No it won't will. It **might**. Hence the question, which btw remains unanswered by your post. ¶¶ re *"finish(); on itself and in the onDestroy kills the LocationListener and other variables you had invoked"*. Why the roundabout when you can do that right at the place where you call `finish()`? – Pacerier May 09 '20 at 15:11
  • @xmen, close no cigar.. OP didn't talk about `isFinishing` but `onPause`. (And in fact `onPause` doesn't trigger if the user clears the backstack. though yes **if** onStop/onDestroy follows that, `isFinishing` is true.) – Pacerier May 09 '20 at 16:39
3

Can you describe a real-app situation (i.e. not analogy to driving a car etc.) in which it would make sense to implement onDestroy()?

When you want to capture a configuration change. It's all in the SDK: http://developer.android.com/reference/android/app/Activity.html