0

This SO question deals with the memory leak caused by saving the View instance returned by a fragment, allowing the onCreateView of a fragment to return the same View under certain circumstances. The conclusion there is that the saved View will hold the Activity (via Context), never allowing it to release - resulting in a memory leak.

My question in this context, is: If I'm implementing my whole app in a single activity, could I consider this problem as irrelevant? Or are there other considerations not to save it?

Thanks! Danny.

Edit: To make things worse, what would be the case if the View is given as a parameter to the Fragment constructor?

Community
  • 1
  • 1
DannyA
  • 1,571
  • 2
  • 17
  • 28

1 Answers1

0

The problem is not irrelevant - this same issue could hit your app in the normal Activity lifecycle.

The best solution is to use the View.onSaveInstanceState(), and View.onRestoreSavedInstanceState(Bundle) methods to handle restoring your Views properly. Unless you're doing something particularly esoteric, these should be all you need.

Dave
  • 6,064
  • 4
  • 31
  • 38
  • Thanks! I think my case might be quite esoteric, as you said. The problem is that I very much want to save the `View` itself, and not just a few state params. The reason is that the whole view hierarchy I wish to save is created in runtime and handed to the `Fragment`, through a slightly complicated mechanism, and recreating it may be very inefficient. I'm not sure I see where in the lifecycle of the Activity this may happen? Wouldn't the worse case be that the activity is killed, in which case the Fragment dies with it? Thanks. – DannyA Oct 23 '11 at 12:37