I didn't meant to imply that I wanted updated documentation this weekend. Lord no! I've heard you're the hardest working team in mobile ;-) and I believe it, but your weekends should still belong to you to do as you please. I'm very grateful that you choose to spend a big chunk of your spare time helping all of us. I will consider the part about setting arguments stricken from the docs. That's good enough for me.
My comments about the arguments bundle were not meant as advice to anyone. Quite the opposite. The documentation says that you can't set the arguments bundle after the fragment is attached to the activity. I can imagine some developer realizing as I did that you can get around it, and then they'll wonder why their fragments don't behave properly. There should be no reason to muddy up that bundle with anything other than the initialization values. - dave On Feb 19, 5:43 pm, Dianne Hackborn <hack...@android.com> wrote: > This working as I expect it to. What happens is when an activity is being > restored from its state, all of the previously known fragments must first be > created so that any attempt to check for one will succeed, instead of > reporting that it doesn't exist, allowing the app to create a new one, which > now conflicts with the one that will be later restored from the saved state. > > I don't have any update documentation to share with you right now. I am at > home, on a weekend, answering questions in my spare time. I'll update the > documentation when I have a chance at work, and that will be in whatever the > next SDK release is. For now, just cross out the part about using it to set > arguments. > > Also I would suggest not going around the back of things to directly change > the argument bundle. If only Java had a concept of const. :p > > On Sat, Feb 19, 2011 at 1:34 PM, davemac <davemac...@gmail.com> wrote: > > I also noticed that while you can't call setArguments() after the > > fragment has been attached to an activity, you can get the arguments > > bundle and add or modify its contents. This means in theory I could > > update the arguments bundle in onInflate() if the bundle already > > exists on the fragment, even if onInflate() occurs after onAttach() > > and onCreateView() on the restart. But it also means that if I > > accessed the arguments bundle in any previous step of a fragment's > > restoration, I could get different behavior the next time, for example > > when that fragment is restored because of the back stack. And of > > course all of that would be bad. So is there a good reason why > > onInflate() does not get called prior to onAttach() on a restart? > > > Also, could you please share the updated documentation with us sooner > > rather than later? > > > - dave > > > On Feb 19, 4:20 pm, davemac <davemac...@gmail.com> wrote: > > > The behavior still looks odd to me. On an activity restart, when > > > setContentView() is called in the activity's onCreate(), you'll most > > > likely be inflating a new activity layout if you've done a rotation. > > > But because it's a configuration change, the existing fragments are > > > saved and restored behind the scenes (well, sort of). The onInflate() > > > method does get called on the fragment that had been originally > > > instantiated from a <fragment> tag in the old layout for the activity, > > > but it fires only after onCreateView() has already happened on that > > > fragment. So either the onInflate() doesn't need to fire at all > > > because it's too late to do anything, or it's firing too late. Which > > > tells me it's not just a documentation change. > > > > - dave > > > > On Feb 19, 4:00 pm, Dianne Hackborn <hack...@android.com> wrote: > > > > > Thanks, I'll update the documentation. > > > > > On Sat, Feb 19, 2011 at 12:46 PM, davemac <davemac...@gmail.com> > > wrote: > > > > > I was just going by what the documentation says. This is from > > > > > onInflate(): > > > > > > >>> Start Android documentation... > > > > > Called when a fragment is being created as part of a view layout > > > > > inflation, typically from setting the content view of an activity. > > > > > This will be called immediately after the fragment is created from a > > > > > tag in a layout file. Note this is before the fragment's > > > > > onAttach(Activity) has been called; all you should do here is parse > > > > > the attributes and save them away. A convenient thing to do is simply > > > > > copy them into a Bundle that is given to setArguments(Bundle). > > > > > > This is called every time the fragment is inflated, even if it is > > > > > being inflated into a new instance with saved state. Because a > > > > > fragment's arguments are retained across instances, it may make no > > > > > sense to re-parse the attributes into new arguments. You may want to > > > > > first check getArguments() and only parse the attributes if it > > returns > > > > > null, the assumption being that if it is non-null those are the same > > > > > arguments from the first time the fragment was inflated. (That said, > > > > > you may want to have layouts change for different configurations such > > > > > as landscape and portrait, which can have different attributes. If > > so, > > > > > you will need to re-parse the attributes each time this is called to > > > > > generate new arguments.) > > > > > >>> Stop Android documentation... > > > > > > The AttributeSet passed to onInflate() will contain the attributes > > > > > from the <fragment> tag in the newest layout file, i.e., the one for > > > > > the configuration I'm now in. These attributes could have changed > > with > > > > > an orientation change, and are meaningful to my fragment that I'm > > > > > building, but they will not be available to my fragment at all until > > > > > it's too late. As it stands now, I have no way to re-parse the > > > > > attributes to generate new arguments. > > > > > > - dave > > > > > > On Feb 19, 3:16 pm, Dianne Hackborn <hack...@android.com> wrote: > > > > > > Oh and it really doesn't make sense to set the arguments from the > > inflate > > > > > > attributes. I mean, the arguments are the ones coming from the > > content > > > > > view > > > > > > hierarchy. You don't need to save them away, that just duplicates > > them > > > > > > elsewhere, and potentially leads to ambiguous situation such as if > > you > > > > > have > > > > > > different arguments for different layouts, in which case should the > > last > > > > > > restored arguments be used or the ones from the new layout? > > > > > > > On Sat, Feb 19, 2011 at 12:14 PM, Dianne Hackborn < > > hack...@android.com > > > > > >wrote: > > > > > > > > Well basically onInflate() is called when it needs to be, which > > is when > > > > > the > > > > > > > content view of the activity is being inflated. If that isn't > > working > > > > > for > > > > > > > you... you will need to do something else. There is no other > > point at > > > > > > > which this can be called, the on and only point it can happen is > > during > > > > > > > inflation of the activity's view hierarchy. > > > > > > > > On Sat, Feb 19, 2011 at 11:53 AM, davemac <davemac...@gmail.com> > > > > > wrote: > > > > > > > >> I created a bug report for this a couple of days ago, but it > > doesn't > > > > > > >> seem to have received any attention: > > > > > > > >>http://code.google.com/p/android/issues/detail?id=14796 > > > > > > > >> To reproduce the problem, add the following callback override to > > the > > > > > > >> TitlesFragment class in FragmentLayout.java under the ApiDemos > > project > > > > > > >> in samples for Honeycomb Preview: > > > > > > > >> @Override > > > > > > >> public void onInflate(AttributeSet attrs, Bundle > > > > > > >> savedInstanceState) { > > > > > > >> Bundle args = new Bundle(); > > > > > > >> for(int i=0; i<attrs.getAttributeCount(); i++) { > > > > > > >> Log.v("14796", " " + attrs.getAttributeName(i) > > + > > > > > > >> " = " + > > attrs.getAttributeValue(i)); > > > > > > >> args.putString(attrs.getAttributeName(i), > > > > > > >> attrs.getAttributeValue(i)); > > > > > > >> } > > > > > > >> this.setArguments(args); > > > > > > >> super.onInflate(attrs, savedInstanceState); > > > > > > >> } > > > > > > > >> This is doing what the the documentation says you should do. > > That is, > > > > > > >> take attributes passed in and save them in the arguments bundle > > on the > > > > > > >> fragment instance. However, if you launch this activity then > > rotate > > > > > > >> the screen, the activity crashes with an IllegalStateException. > > And it > > > > > > >> does that because onInflate() gets called way too late when > > Android is > > > > > > >> rebuilding the activity and its fragments. If the layout for the > > other > > > > > > >> orientation is different that the previous layout, you'll have > > no way > > > > > > >> to use any of the attributes in onCreateView() for the fragment, > > > > > > >> because onInflate() isn't being called until later. > > > > > > > >> I haven't come up with a workaround either. The fragment can't > > even > > > > > > >> see the activity until onAttach(), and you can't set the > > arguments > > > > > > >> bundle once onAttach() has been called. > > > > > > > >> The sample activities so far haven't tried to utilize this > > feature, so > > > > > > >> perhaps it won't affect most people. But for those who need or > > want > > > > > > >> it, it doesn't seem to work. > > > > > > > >> -- > > > > > > >> 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. > > > > > > > -- > > > > > > 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 > > ... > > read more » -- 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
