Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>1) Why is <code>newInstance</code> needed?</p> <p><code>newInstance</code> methods are needed because the framework encourages you to only ever have one constructor, taking no arguments. Having more than one constructor is somewhat frowned upon. </p> <p>It needs this constructor to be public, so that it can recreate you Fragments when, for example, you undergo a configuration change. The same <code>Bundle</code> that you passed to <code>setArguments</code> on the original will be given to the copy too (as well as a <code>savedInstanceState</code> <code>Bundle</code> from <code>onSaveInstanceState</code>).</p> <p>Doing this for all fragments, including ones that have no arguments leads to consistent usage of fragments and ease of maintenance. Namely, do make sure to always pass an arguments <code>Bundle</code>, even if it's empty, so that you don't have to check <code>getArguments()</code> for <code>null</code>.</p> <p>2) <code>onCreate</code> in the <code>Fragment</code> lifecycle.</p> <p>The <code>Fragment</code> lifecycle is officially called "nested" but when adding new fragments I like to think of it as "playing catch up". For example, if your Activity has started (has had its <code>onStart</code> called), your Fragment will get a rapid succession of <code>onAttach</code>, <code>onCreate</code>, <code>onActivityCreated</code>, <code>onCreateView</code>, <code>onStart</code> in essence catching up to the Activity's lifecycle. You can enable debugging with <code>FragmentManager.enableDebugLogging(true);</code> to track the lifecycle changes - look for <code>moveto</code> (forward direction) and <code>movefrom</code> (rewinding the cycle - destroying/detaching the fragment). </p> <p>That said, <code>onCreate</code> is kinda easy to predict - since you're probably first creating the fragment after <code>onCreate</code> of the Activity, it would be called almost immediately when the transaction executes.</p> <p>However, if you undergo a configuration change, the Fragments are destroyed with the old Activity and then created <em>before</em> the new Activity (it happens in that <code>super.onCreate(savedInstanceState)</code> call that you have in your Activity) - <code>onCreate</code> of all the fragments will be called before the Activity's <code>onCreate</code> returns. Once it returns, the Fragments' <code>onActivityCreated</code> will be called and from then on the fragments and activity will move in lockstep. This is all unless you have <code>setRetainInstance(true)</code>, of course.</p> <p>I hope this clears it up. I strongly suggest enabling debugging and just playing around with the fragments to get a better feeling for their lifecycles.</p>
 

Querying!

 
Guidance

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