"reduces the memory leak of an activity." should read "reduces the *risk of a *memory leak of an activity.
On Thursday, November 15, 2012 9:47:25 AM UTC-5, Streets Of Boston wrote: > > Some quick answers to your questions :) > > 1. I use loaders mainly in fragments. Since fragments can be retained > across configuration changes (setRetainInstance(true)), loaders tied to > these fragments are retained across configuration changes as well. > Also, delivery to your UI when data has been loaded is handled for you by > loaders; you don't have to write code checking if the activity still exists > if the data is delivered, etc. This makes your code less error prone and > reduces the memory leak of an activity. > > 2. Initialize the loader in the onCreate (of a Fragment). If the fragment > is retained, then you shouldn't see an empty list 'flash' when the device > is rotated: The data from your loader should still be available. > > 3. Yes, but it depends what object initializes/loads the loader. See my > previous remarks about using them in fragment that are retained. > > 4. Using a ContentObserver/ContentProvider would allow you to easily use > CursorLoaders. > > 5. Again: Use a fragment that is retained and that show the 'loading' > animation: > When starting to load data, set a boolean that is a field in your fragment > to 'true' and show the loading... animation. > In onStop stop the loading... animation. > In onStart, if the loading boolean is true, show the loading... animation > (again). > When data has been loaded, stop the loading... animation and set the > loading boolean to 'false'. > > > On Wednesday, November 14, 2012 9:38:15 PM UTC-5, Evan Ruff wrote: >> >> Hey guys, >> >> I'm beginning to bring my application out of the dark ages (API 7) up to >> the more recent stuff and I'd like to migrate from my current Singleton >> data provider to something like the Loader paradigm. I had a couple of >> question. Currently, when the Application starts, I pull all of my objects >> out of the database and hold them in a singleton User object on the >> Application. The Activities then pass around ID references which query the >> singleton for values. This breaks down rather dramatically when the >> application is terminated and doesn't really jive well with "the Android >> way." I've started to do some testing with loaders and have based my test >> implementation off the follow tutorial: >> >> http://www.androiddesignpatterns.com/2012/08/implementing-loaders.html >> >> Couple Questions: >> 1. Are loaders special? Are they handled differently from a LifeCycle >> perspective or is it simply a more streamlined way of doing loading in an >> AsyncTask then returning it to the Activity? >> >> 2. There always seems to be a nasty flash of an empty list on my >> Activities. Should the onResume check for a load and load immediately? >> (deliverResults?) >> >> 3. Do the loaders save state in an onSaveInstanceState sort of way? >> >> 4. I'm a little foggy on the ContentObserver. My data is backed up by the >> SQLlite DB... is a ContentObserver "better", or should I just manually >> invoke BroadcastReceivers when my application pulls down new data? >> >> 5. How should I handle loading animations in the Activity? Traditional >> way of start/stopping the "Loading" animation? My question is around >> when... show ProgressBar in onResume and hide it on onLoadFinished? >> >> Thanks for any pointers! >> >> E >> > -- 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
