Thank you for the quick response. This really clarifies things for me! Appreciate the help,
E On Thursday, November 15, 2012 9:49:28 AM UTC-5, Streets Of Boston wrote: > > "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
