Ok. got it. thanks On Fri, Feb 18, 2011 at 12:45 PM, Dianne Hackborn <hack...@android.com> wrote: > 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 > <satya.komatin...@gmail.com> 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 <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 >> >> >> >> -- >> 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 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
-- 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 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
