I had seen and appreciate the putFragment() method of FragmentManager. Quick follow-on question on that: you aren't necessarily guaranteed to get back the same in-memory instance of a fragment saved with putFragment() when you call getFragment(), but you won't be able to tell the difference, unless you've used internal variables and not saved/restored them in onSaveInstanceState() and one of the startup callbacks, correct?
I had not fully understood the meaning and use of target fragments. The FragmentRetainInstance example under API Demos is helpful in this regard. If fragment A wants to communicate with fragment B, I'm assuming that fragment A must know whether or not fragment B is part of the current activity, or would be in a separate activity (in the case this is running on a smaller screen, or just because). Is that also true? I'm assuming that a fragment manager is per activity, and that a fragment in a different activity should not be directly "talking" to a fragment in the first activity. - dave On Feb 18, 1:13 am, Dianne Hackborn <hack...@android.com> wrote: > No, actually, one of the big benefits of fragments is that they are *not* > sub-activities, they don't try to have a pretense of being isolated from > each other, and are designed to allow you to easily use direct pointers to > them. > > Don't try to impose "object oriented" because you feel like this somehow > magically makes things better. Unless it serves a purpose, it doesn't. > > Anyway there is a perfectly fine way to do these interactions that most > people will agree is object oriented and makes the code much simpler and > lighter weight: define a callback interface that one fragment (or activity) > implements and another can then call. > > See for example the built-in facility for a fragment to have a pointer to a > target fragment. This is the fragment version of activity's > onActivityResult(). However because fragments don't have a goal of imposing > a strict (remote-able) high-level interface to itself, sending results > between fragments is a lot easier: just define an interface of whatever > functionality you want, which the target fragment can implement, and the > sending can cast and call on. > > You can also take advantage of the FragmentManager APIs to save a fragment > "pointer" in a bundle and later retrieve it, to allow you to maintain direct > pointers across state save/restore. > > Basically, with fragments you'll want to unlearn a lot of the painful things > you got used to dealing with in embedded activities. :) > > > > On Thu, Feb 17, 2011 at 8:10 PM, davemac <davemac...@gmail.com> wrote: > > I'd love to hear opinions on the best way to communicate between > > fragments. > > > If we consider that fragments are like sub-activities (a common > > metaphor), then we might think to use broadcast messages to tell one > > fragment about something that happened in another fragment. That seems > > a bit difficult though not impossible. > > > The samples simply lookup one fragment from another then access views > > directly. This forces that fragment to understand what's going on > > around it, which doesn't feel as object-oriented as I'd like. I'd feel > > better if maybe the activity was doing that sort of coordination, so > > the fragment tells the activity, and the activity figures out which > > other fragment, if any, needs to get a message, then invokes a method > > on the fragment so it can perform any updates. Or the activity could > > decide we're in a situation where we need to fire up a separate > > activity. Or maybe move things around on the screen. > > > Am I over-complicating things here? I realize that a mobile app should > > be as compact as possible, and if that means "just do it" and access > > views in other fragments directly, then I could go along with that. > > But I thought I'd ask the group to get some other opinions. > > > - dave > > > -- > > 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
