Like I said, there are APIs on FragmentManager to put a Fragment pointer in a Bundle and pull it out again, which work across state save/restore.
Though probably just as often, you can just use a tag name (or view ID) for the fragment and later re-retrieve it when being created though findFragmentByTag() and findFragmentById(). On Fri, Feb 18, 2011 at 9:22 AM, Satya Komatineni < [email protected]> wrote: > You say one can hold direct pointers (not just their references such > as id and tag) to fragments of an activity. > > won't these pointers go stale across save/restore of either an > activity or fragment? > > May be a "targetfragment" pointer may be retrofitted by the fragment > manager (perhaps!!). How is this maintained across save/restore? > > how about the holding activity having an explicit pointer as a local > variable of one of its child fragments? what about this pointer? as > fragments go popping out of stack it is possible that the activity may > hold on to each of these stacked fragments. (Ofcourse there is the > find by tag or id of those in the current stack) > > I suspect these local pointers to other fragments may need to be > explicitly managed through save/restore states?? > > Thanks for helping us demystify a few things... > > Satya > > On Fri, Feb 18, 2011 at 1:13 AM, Dianne Hackborn <[email protected]> > 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 <[email protected]> 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 > [email protected] > >> To unsubscribe from this group, send email to > >> [email protected] > >> For more options, visit this group at > >> http://groups.google.com/group/android-developers?hl=en > > > > > > > > -- > > Dianne Hackborn > > Android framework engineer > > [email protected] > > > > 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 [email protected] > > To unsubscribe from this group, send email to > > [email protected] > > For more options, visit this group at > > http://groups.google.com/group/android-developers?hl=en > > > > -- > Satya Komatineni > http://www.satyakomatineni.com > http://www.androidbook.com > > -- > You received this message because you are subscribed to the Google > Groups "Android Developers" group. > To post to this group, send email to [email protected] > To unsubscribe from this group, send email to > [email protected] > For more options, visit this group at > http://groups.google.com/group/android-developers?hl=en > -- Dianne Hackborn Android framework engineer [email protected] 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 [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
