Thank you for the reply. I had second thoughts about my post and
removed it, but you're right on top of things, as usual ;-) As you
said, the arguments Bundle is critical for the proper restoration of a
Fragment if it gets saved away. What I wondered about was the code on
the client side where somebody would have to write several lines of
code to create the Fragment object, then a Bundle object, assign the
values, and add the Bundle. So while it is a requirement to have a
default constructor, and for new instances of my Fragment object to
get an arguments Bundle attached, I could in fact create other
constructors that take care of that Bundle setup/attach work on behalf
of the client, yes? In other words, the following should be okay I
think (typing quickly and with insufficient coffee):
public class MyFragment extends Fragment {
public MyFragment() {}
public MyFragment(int index) {
MyFragment f = new MyFragment();
Bundle args = new Bundle();
args.add("index", index);
f.setArguments(args);
}
[ ... ]
}
Now the clients of MyFragment can instantiate one with arguments much
easier, yet I still get the recoverability because I do the right
things behind the scenes.
- dave
On Feb 14, 12:18 am, Dianne Hackborn <hack...@android.com> wrote:
> Actually the big reason for using a Bundle is because this needs to be saved
> as part of the saved instance state of the activity. The Bundle class
> provides a data structure that is Parcelable (can be saved) and
> automatically takes care of the marshalling/unmarshalling for you (so the
> app developer won't need to deal with that complexity).
>
> If you use a constructor that takes an int, you will then need to write the
> code in onSaveInstanceState() to store the int and retrieve it in
> onCreate(). Since you are going to be dealing with bundles, anyway, you
> might as well just have it in a bundle up-front and let the framework take
> care of the saving and restoring.
>
> In fact the whole arguments API was added to fragment just to reduce the
> amount I was seeing that you had to write that save/restore boilerplate
> code.
>
> Of course if you don't really care about retaining your arguments across
> instances, then there is no reason to use the formal arguments bundle and go
> ahead and have a constructor with the typed arguments. That said, if you
> think this is the case, there is probably a 90% chance you actually aren't
> realizing that you *do* need to have those arguments saved so will run into
> problems later.
>
> Also you need to be aware that a fragment needs to have an empty constructor
> so it can be re-created later from saved state, so if you do have a
> constructor with arguments, you need to be sure to also explicitly write an
> empty constructor.
>
>
>
> On Sun, Feb 13, 2011 at 2:32 PM, davemac <davemac...@gmail.com> wrote:
> > I think I understand the logic behind using Bundles to pass in and
> > store values associated with a Fragment, but I wondered if someone
> > could validate my understanding.
>
> > I believe that it makes sense to use a Bundle to pass in initial
> > values at the time of construction of a Fragment for a number of
> > reasons:
> > 1) Bundles are a simple way to pass in an arbitrary number of
> > arguments of different types, so the pattern of using Fragments is the
> > same for everyone. This makes understanding them easier.
> > 2) The arguments Bundle on a Fragment (setArguments, getArguments)
> > is a convenience over having to create class member fields to keep
> > track of the specifics of a Fragment object.
> > 3) It is simple to take an extras Bundle from an inbound Intent
> > and pass it to a Fragment's creation logic.
>
> > This doesn't mean you always need to use a Bundle when creating a
> > Fragment, but if you have a few or more values to pass in, a Bundle
> > makes a lot of sense. Are there other reasons why you'd want to use
> > Bundles in this way? Or situations where you wouldn't? The Shakespeare
> > example that Dianne blogged about recently used a Bundle for a single
> > int value. Was this more for demonstration purposes? Or would it have
> > been acceptable to simply use a constructor that takes an int, and
> > save it in a member field for later? Thanks!
>
> > --
> > You received this message because you are subscribed to the Google
> > Groups "Android Developers" group.
> > To post to this group, send email to android-developers@googlegroups.com
> > To unsubscribe from this group, send email to
> > android-developers+unsubscr...@googlegroups.com
> > For more options, visit this group at
> >http://groups.google.com/group/android-developers?hl=en
>
> --
> Dianne Hackborn
> Android framework engineer
> hack...@android.com
>
> Note: please don't send private questions to me, as I don't have time to
> provide private support, and so won't reply to such e-mails. All such
> questions should be posted on public forums, where I and others can see and
> answer them.
--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
