StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<p>First of all, check out <a href="http://www.androiddesignpatterns.com/2013/04/retaining-objects-across-config-changes.html" rel="noreferrer"><strong>my post</strong></a> on retained Fragments. It might help.</p> <p>Now to answer your questions:</p> <blockquote> <p>Does the fragment also retain its <s>view</s> state, or will this be recreated on configuration change - what exactly is "retained"?</p> </blockquote> <p>Yes, the <code>Fragment</code>'s state will be retained across the configuration change. Specifically, "retained" means that the fragment will <em>not</em> be destroyed on configuration changes. That is, the <code>Fragment</code> will be <em>retained</em> even if the configuration change causes the underlying <code>Activity</code> to be destroyed.</p> <blockquote> <p>Will the fragment be destroyed when the user leaves the activity?</p> </blockquote> <p>Just like <code>Activity</code>s, <code>Fragment</code>s may be destroyed by the system when memory resources are low. Whether you have your fragments retain their instance state across configuration changes will have no effect on whether or not the system will destroy the <code>Fragment</code>s once you leave the <code>Activity</code>. If you leave the <code>Activity</code> (i.e. by pressing the home button), the <code>Fragment</code>s may or may not be destroyed. If you leave the <code>Activity</code> by pressing the back button (thus, calling <code>finish()</code> and effectively destroying the <code>Activity</code>), all of the <code>Activity</code>s attached <code>Fragment</code>s will also be destroyed.</p> <blockquote> <p>Why doesn't it work with fragments on the back stack?</p> </blockquote> <p>There are probably multiple reasons why it's not supported, but the most obvious reason to me is that the <code>Activity</code> holds a reference to the <code>FragmentManager</code>, and the <code>FragmentManager</code> manages the backstack. That is, no matter if you choose to retain your <code>Fragment</code>s or not, the <code>Activity</code> (and thus the <code>FragmentManager</code>'s backstack) will be destroyed on a configuration change. Another reason why it might not work is because things might get tricky if both retained fragments <em>and</em> non-retained fragments were allowed to exist on the same backstack.</p> <blockquote> <p>Which are the use cases where it makes sense to use this method?</p> </blockquote> <p>Retained fragments can be quite useful for propagating state information — especially thread management — across activity instances. For example, a fragment can serve as a host for an instance of <code>Thread</code> or <code>AsyncTask</code>, managing its operation. See <a href="http://www.androiddesignpatterns.com/2013/04/retaining-objects-across-config-changes.html" rel="noreferrer"><strong>my blog post</strong></a> on this topic for more information.</p> <p>In general, I would treat it similarly to using <code>onConfigurationChanged</code> with an <code>Activity</code>... don't use it as a bandaid just because you are too lazy to implement/handle an orientation change correctly. Only use it when you need to.</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