Off-hand, I think it would be easier to implement a custom loader that knows how to load the data once and share it across all requests.
On Tue, Nov 8, 2011 at 1:06 PM, Chris Stewart <cstewart...@gmail.com> wrote: > I'm working on implementing ViewPager and I want to let the host activity > load the background data (from the Internet) instead of each fragment doing > an independent I/O request. The reason why is because the same data is > being loaded into two fragments, with the only difference being a category. > I have two instances of ViewPager in my app, where this scenario holds > true (two different types of data, but each being split by only a > category). If I can let the host activity fetch the data in the > background, I'll be saving 2 API calls every time the app is used. > > I want to let the ViewPager and it's fragments know when to update > themselves when the background load is finished so I can fetch the data > once and pass it down into the fragments. However, I can't seem to find > any examples of this. I've tried getting the fragments from the adapter > when the data load is complete, but I'm running into various > synchronization problems. I've tried calling notifyDataSetChanged on the > adapter (subclass of FragmentPagerAdapter), but it doesn't appear to do > anything. > > Another piece to this puzzle is that I'm using ViewPagerIndicator to get > the title effect seen in the Android Market and Google+ apps. I've tried > not initializing the FragmentPagerAdapter, ViewPager, > and TitlePageIndicator until after the data load is complete, but I'm > seeing the TitlePageIndicator attempt to be drawn anyway and failing when > calculating the bounds since it hasn't been given a ViewPager instance just > yet. > > Has anyone else tried to use the ViewPager is this scenario? I think if I > found a nice outline of how the ViewPager's lifecycle works, I would have > better luck in figuring this workflow out. Every example I can find lets > the fragments self contain everything, which I completely understand the > reasoning behind and will go that route if necessary but would love to cut > the required network I/O requests if possible. > > -- > Chris Stewart > > -- > 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
