Re: [android-developers] Understanding the lifecycle of ViewPager
It seems like the Loader is now a replacement for AsyncTask, but does it also replace the use of a Runnable/Thread scenario? The AsyncTask is more difficult to set up, so I understand why a Loader makes sense there ( http://stackoverflow.com/questions/5603504/android-3-0-what-are-the-advantages-of-using-loadermanager-instances-exactly). In my scenarios, I have data being loaded from a web service but there's a progress dialog and action only needs to be taken after the process is completed. So for this I've always created a runnable, started a new thread from that, and have an on UI runnable that's called after the processing is completed. Should I instead be looking at using Loaders for this moving forward? -- Chris Stewart On Wed, Nov 9, 2011 at 7:03 AM, Mark Murphy mmur...@commonsware.com wrote: On Tue, Nov 8, 2011 at 10:51 PM, Chris Stewart cstewart...@gmail.com wrote: Thanks for the reply Dianne. I'm not completely sure what you mean by custom loader, are you referring to what was introduced in 3.2? If so, is it available in the support library for pre-3.2? The Loader framework is in the Android support package / compatibility library / thingy. :-) -- Mark Murphy (a Commons Guy) http://commonsware.com | http://github.com/commonsguy http://commonsware.com/blog | http://twitter.com/commonsguy Warescription: Three Android Books, Plus Updates, One Low Price! -- 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 -- 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
Re: [android-developers] Understanding the lifecycle of ViewPager
Loader is not a replacement for AsyncTask. In fact, Loader itself does nothing, it is just the hook into interacting with the lifecycle of LoaderManager/Activity/Fragment. AsyncTaskLoader is a Loader that uses an AsyncTask to do its loading on a separate thread. This also is not a replacement for AsyncTask; it is a convenience for doing background operations via AsyncTask that is managed on conjunction with the lifecycle of the LoaderManager/Activity/Fragment. If AsyncTaskLoader makes it easy to do what you want, then great use that. If not, then use whatever works best for you -- AsyncTask, a Thread, etc. On Mon, Nov 28, 2011 at 8:00 AM, Chris Stewart cstewart...@gmail.comwrote: It seems like the Loader is now a replacement for AsyncTask, but does it also replace the use of a Runnable/Thread scenario? The AsyncTask is more difficult to set up, so I understand why a Loader makes sense there ( http://stackoverflow.com/questions/5603504/android-3-0-what-are-the-advantages-of-using-loadermanager-instances-exactly). In my scenarios, I have data being loaded from a web service but there's a progress dialog and action only needs to be taken after the process is completed. So for this I've always created a runnable, started a new thread from that, and have an on UI runnable that's called after the processing is completed. Should I instead be looking at using Loaders for this moving forward? -- Chris Stewart On Wed, Nov 9, 2011 at 7:03 AM, Mark Murphy mmur...@commonsware.comwrote: On Tue, Nov 8, 2011 at 10:51 PM, Chris Stewart cstewart...@gmail.com wrote: Thanks for the reply Dianne. I'm not completely sure what you mean by custom loader, are you referring to what was introduced in 3.2? If so, is it available in the support library for pre-3.2? The Loader framework is in the Android support package / compatibility library / thingy. :-) -- Mark Murphy (a Commons Guy) http://commonsware.com | http://github.com/commonsguy http://commonsware.com/blog | http://twitter.com/commonsguy Warescription: Three Android Books, Plus Updates, One Low Price! -- 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 -- 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
Re: [android-developers] Understanding the lifecycle of ViewPager
I see, and that makes more sense. Thanks for the explanation. While using an AsyncTaskLoader wasn't completely necessary for what I'm doing, I have it all working and it wasn't complicated to get going. So I'll call that a win-win. I did manage to solve the original intent of this question today by creating an AsyncTaskLoader that understands how to load in all of the data the fragments in my ViewPager need. Thanks for the direction, the app is behaving exactly how I'd like now. -- Chris Stewart On Mon, Nov 28, 2011 at 3:11 PM, Dianne Hackborn hack...@android.comwrote: Loader is not a replacement for AsyncTask. In fact, Loader itself does nothing, it is just the hook into interacting with the lifecycle of LoaderManager/Activity/Fragment. AsyncTaskLoader is a Loader that uses an AsyncTask to do its loading on a separate thread. This also is not a replacement for AsyncTask; it is a convenience for doing background operations via AsyncTask that is managed on conjunction with the lifecycle of the LoaderManager/Activity/Fragment. If AsyncTaskLoader makes it easy to do what you want, then great use that. If not, then use whatever works best for you -- AsyncTask, a Thread, etc. On Mon, Nov 28, 2011 at 8:00 AM, Chris Stewart cstewart...@gmail.comwrote: It seems like the Loader is now a replacement for AsyncTask, but does it also replace the use of a Runnable/Thread scenario? The AsyncTask is more difficult to set up, so I understand why a Loader makes sense there ( http://stackoverflow.com/questions/5603504/android-3-0-what-are-the-advantages-of-using-loadermanager-instances-exactly). In my scenarios, I have data being loaded from a web service but there's a progress dialog and action only needs to be taken after the process is completed. So for this I've always created a runnable, started a new thread from that, and have an on UI runnable that's called after the processing is completed. Should I instead be looking at using Loaders for this moving forward? -- Chris Stewart On Wed, Nov 9, 2011 at 7:03 AM, Mark Murphy mmur...@commonsware.comwrote: On Tue, Nov 8, 2011 at 10:51 PM, Chris Stewart cstewart...@gmail.com wrote: Thanks for the reply Dianne. I'm not completely sure what you mean by custom loader, are you referring to what was introduced in 3.2? If so, is it available in the support library for pre-3.2? The Loader framework is in the Android support package / compatibility library / thingy. :-) -- Mark Murphy (a Commons Guy) http://commonsware.com | http://github.com/commonsguy http://commonsware.com/blog | http://twitter.com/commonsguy Warescription: Three Android Books, Plus Updates, One Low Price! -- 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 -- 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 -- 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
Re: [android-developers] Understanding the lifecycle of ViewPager
On Tue, Nov 8, 2011 at 10:51 PM, Chris Stewart cstewart...@gmail.com wrote: Thanks for the reply Dianne. I'm not completely sure what you mean by custom loader, are you referring to what was introduced in 3.2? If so, is it available in the support library for pre-3.2? The Loader framework is in the Android support package / compatibility library / thingy. :-) -- Mark Murphy (a Commons Guy) http://commonsware.com | http://github.com/commonsguy http://commonsware.com/blog | http://twitter.com/commonsguy Warescription: Three Android Books, Plus Updates, One Low Price! -- 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
[android-developers] Understanding the lifecycle of ViewPager
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
Re: [android-developers] Understanding the lifecycle of ViewPager
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
Re: [android-developers] Understanding the lifecycle of ViewPager
Thanks for the reply Dianne. I'm not completely sure what you mean by custom loader, are you referring to what was introduced in 3.2? If so, is it available in the support library for pre-3.2? I'm looking for similar functionality found, or at least perceived to be, in the Google+ app. You can see the loading image working in the Action Bar, seemingly showing overall progress for the fragments inside the ViewPager. Chris Stewart http://locomolabs.com On Nov 8, 2011 6:43 PM, Dianne Hackborn hack...@android.com wrote: 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.comwrote: 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 -- 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
