1

Fragments are recreated automatically when their parent Activity or Fragment is recreated. If the child fragments were related to state that is not retained between instances of their parent, when should I remove them?

  • In the parent fragment's onDestroy(): unreliable since onDestroy() might not be called.
  • In the parent fragment's onCreate(): presumably the children have not yet been created at this point.
  • Some other lifecycle method that is guaranteed to be called after the children have been recreated and added. Is onViewStateRestored(...) the right place for this?

In case my question isn't clear, here's an example:

An Activity has a Fragment which contains an asynchronous operation. The fragment would normally cancel this task in onDestroy(). But if the fragment is destroyed without onDestroy() being called, it may later find itself recreated with the background task uninitialized. In that case, it should remove its old progress dialog. When should it test for this condition?

Edit: When the user swipes the app out of recents, all its components are destroyed without calls to onDestroy(). But in that case, the fragment hierarchy is apparently obliterated along with the rest of the app. When the app is restarted, the fragment is not automatically recreated, so I don't have to worry about removing it.

When the fragment is destroyed because its host activity is put in the background and "don't keep activities" is turned on, the fragment is automatically recreated. But in that case, it seems I can count on onDestroy() being called.

My concern is what happens when the app is killed to free memory. Hopefully it will behave like swiping from recents, where the fragment hierarchy is not restored. That would render my whole question moot. Can anyone confirm what happens in that case?

Community
  • 1
  • 1
Kevin Krumwiede
  • 9,868
  • 4
  • 34
  • 82
  • What do you mean by "destroying a fragment"? The fragment gets destroyed when the system doesn't have any more references to it. As for async operations in the fragment, you can cancel those in onDestroy(). Or in onStop(), that depends on what the app does. – Christine Jul 07 '15 at 00:09
  • if the activity is destroyed so are the fragments contained in it, and the fragments will be destroyed first before the activity, so stop the progress in onStop() or onDestroy() – Brian Jul 07 '15 at 00:36
  • @Christine I mean either `Fragment#onDestroy()` is called, or the process is killed. – Kevin Krumwiede Jul 07 '15 at 01:32
  • @Brian Those methods might never be called. – Kevin Krumwiede Jul 07 '15 at 01:32
  • Possibly related, but different in that it involves the fragment backstack: http://stackoverflow.com/questions/29525097/how-to-remove-fragment-from-fragment-manager-when-activity-is-restored-after-bei?rq=1 – Kevin Krumwiede Jul 07 '15 at 01:49

1 Answers1

0

The docs seem to indicate onpause will always be called https://developer.android.com/guide/components/fragments.html

or if you know the activity is going to be destroyed onDetach() must be called since if the activity is destroyed the fragment can't be attached.

Brian
  • 4,328
  • 13
  • 58
  • 103
  • 1
    `onPause()` is called on a retained fragment during a configuration change, so I don't want to stop background tasks there. And the activity (in fact, the whole app) can be destroyed without anything being called. – Kevin Krumwiede Jul 07 '15 at 02:58
  • check out this post http://www.androiddesignpatterns.com/2013/04/retaining-objects-across-config-changes.html – Brian Jul 07 '15 at 18:59