Why would I ever want `setRetainInstance(false)`? - Or - The correct way to handle device rotation

Question

Please correct me if I\'m wrong on any of this. This is a kind of clarifying question since I haven\'t seen it explicitly written anywhere.

In Android 4, you ca

Answer 1

so that on configuration changes (which basically means device rotation)

And changing locale, changing SIMs, changing default font size, plugging in or removing an external keyboard, putting the device in a dock or removing it from same, etc.

you don't have to deal with onRetainNonConfigurationState()

That's onRetainNonConfigurationInstance().

bundle up all your data so it can be passed to the new Fragment (or Activity) instance only to be unbundled again

Your data should already be "bundled" (e.g., instance of private static inner class) and therefore it would not need to be "bundled" or "unbundled". Also, it frequently should not be "all your data", unless you are a fan of memory leaks.

And I assume (not tested) that resource resolution (layout vs layout-land) works.

Correct.

Is there ever any reason why you would actually want your Fragment to be pointlessly destroyed and recreated on rotation?

Sure.

As you note, all widgets are recreated, so data members tied to widgets are not only unnecessary to retain. Unless you specifically reset those to null on a retained fragment somehow, until onCreateView() is called again, those data members would hold onto the old widgets, which would hold onto the old activity instance, which would prevent that old activity instance from being garbage collected. AFAIK, onCreateView() is not going to be called until the fragment is going to be redisplayed, which may not be for quite some time (the fragment is not used in the new orientation, or the fragment is for some page in a ViewPager that the user visited in the old orientation but does not revisit in the new orientation, etc.). That means that the retained fragment may keep the old activity object around for a substantial period of time. Depending on what else that activity may have held onto (e.g., large Bitmap objects), that could be bad.

Similarly, a fragment that itself holds onto large data, where that fragment may or may not be used after the configuration change, is one that should not be retained.

Also, there will be fragments that simply have nothing needing to be retained (e.g., all data is populated by Loaders, which are already aware of configuration changes and handle them appropriately).

And so on.

A default of fragments being not retained is the safest course of action, with respect to garbage collection issues. You can opt into having some fragments be retained, but then the onus is on you to make sure that you are not screwing yourself by doing that.