StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<blockquote> <p>so that on configuration changes (which basically means device rotation)</p> </blockquote> <p>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.</p> <blockquote> <p>you don't have to deal with onRetainNonConfigurationState()</p> </blockquote> <p>That's <code>onRetainNonConfigurationInstance()</code>.</p> <blockquote> <p>bundle up all your data so it can be passed to the new Fragment (or Activity) instance only to be unbundled again</p> </blockquote> <p>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.</p> <blockquote> <p>And I assume (not tested) that resource resolution (layout vs layout-land) works.</p> </blockquote> <p>Correct.</p> <blockquote> <p>Is there ever any reason why you would actually want your Fragment to be pointlessly destroyed and recreated on rotation?</p> </blockquote> <p>Sure.</p> <p>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 <code>null</code> on a retained fragment somehow, until <code>onCreateView()</code> 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, <code>onCreateView()</code> 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 <code>ViewPager</code> 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 <em>else</em> that activity may have held onto (e.g., large <code>Bitmap</code> objects), that could be bad.</p> <p>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.</p> <p>Also, there will be fragments that simply have nothing needing to be retained (e.g., all data is populated by <code>Loaders</code>, which are already aware of configuration changes and handle them appropriately).</p> <p>And so on.</p> <p>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 <em>you</em> to make sure that you are not screwing yourself by doing that.</p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload