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 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
