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
