Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>I've also stumbled upon this and found a few advantages to using the arguments <code>Bundle</code> over instance fields:</p> <ul> <li><p>If it's in a <code>Bundle</code> the Android system knows about it and can create and destroy your <code>Fragment</code> (using the mandatory parameterless/default constructor and usual lifecycle methods), and just pass in the arguments bundle again. This way no arguments get lost on a low memory killing spree or the eventual orientation changes (this often hits me on first deploy to a real device after development in the less-rotating emulator).</p></li> <li><p>You can just pass the extras <code>Bundle</code> of an <code>Activity</code> as-is to a <code>Fragment</code> embedded in the layout; e.g. I often use this when I have an <code>Activity</code> that displays a <code>Fragment</code> "fullscreen" and needs some ID (or <code>ContentProvider</code> URI) to know what to display/do. I sometimes even add more stuff to a <code>Bundle</code> (or a copy) before I pass it on, e.g.</p> <pre><code>@Override protected void onCreate(final Bundle savedInstanceState) { super.onCreate(savedInstanceState); if (savedInstanceState == null) { // not a re-creation final Bundle args = new Bundle(getIntent().getExtras()); args.putInt(CoverImageFragment.BACKGROUND_RESOURCE, android.R.color.black); final Fragment fragment = CoverImageFragment.newInstance(args); getSupportFragmentManager() .beginTransaction() .add(android.R.id.content, fragment) .commit(); } } </code></pre></li> <li><p>It keeps the way of developing a <code>Fragment</code> close to that of an <code>Activity</code>, i.e. <code>Bundle</code> as "input parameters, no exceptions".</p></li> </ul> <p>As for the downsides you mentioned:</p> <ul> <li><p>I think the overhead is minimal because you most likely won't be querying the <code>Bundle</code> in a tight loop, so getting your argument data out once in <code>onCreate()</code>, <code>onViewCreate()</code>, etc. isn't that bad.</p></li> <li><p>For type-safety, <code>Bundle</code> has all the different <code>getXXXX()</code> methods, and even overloads to provide a default value if a something is missing/optional :)</p></li> </ul> <p>As for the <code>newInstance()</code> methods, I think of them as an easy way to encapsulate the <code>new</code> and <code>setArguments()</code> calls for my <code>Fragment</code>; I sometimes provide an additional <code>MyFragment newInstance(String singleIdOfWhatToDisplay)</code> that creates both the <code>Bundle</code> and <code>Fragment</code> in one go and returns a ready-to-go <code>Fragment</code> instance.</p>
    singulars
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
 

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