How Does AsyncTaskLoader Cache Data?

Question

I have an activity which implements a fragment where all of this code lives. This is best explained through an example as the code is confidential. This example mirrors what is trying to be done and what I observed through testing

ex.) I have a rss reader fragment that fetches two unique objects (A, B) from two unique Loaders with Loader Id's (Loader 1, Loader2)

Object A: 

int[] fullArticleIdList;
List<ArticlePreview> partialArcticlePreviewList;

Object B:

List<ArticlePreview> partialArcticlePreviewList;

At creation I call "initloader" on Loader 1 which fetches object A. After scrolling through the available articles it hits the bottom of the partialArcticlePreviewList returned from object A and fetches more articles using "restartloader on Loader 2 which fetches object B and allows the user to read them and continues to do this for all the articles.

This works fine until the user rotates the devices thus calling onCreate. Now when initloader is called on Loader 1, it immediately jumps to onLoadFinished after connecting to loader 1 and returns a Loader 1. While the articleIds are returned properly, the partialArcticlePreviewList returned is the one from Loader 2 that fetched object B.

Does loader manager only keep one instance of an object around in cache and share it between multiple loaders? It would seem from extensive testing (5+ hours trying to find the problem and looking at loader ID's/Caches/Addresses in the Eclipse Debugger) that it overwrote Loader 1's partialArcticlePreviewList with the data it recieved in Loader 2's partialArcticlePreviewList. While this situation is ideal for a single Loader I would have thought that each Loaders' cache would be seperate. Obviously one of the advantages of loaders was their ease of use and persistence through screen rotation and data caching but it doesn't seem to work as implied. We've circumvented the problem by retaining an instance of the fragment and writing the appropriate code in onCreateView and onDestroyView to avoid memory leaks but is this a good solution?

EDIT: Forgot to add, we're using the compatibility library v4. Also, looking at the android source for the loaders didn't seem to shed any light on the situation as to why the loader is returning the wrong data for it's "mId".

score 3 · Accepted Answer · answered Aug 10 '12 at 18:34

The final solution used to circumvent this problem was simply to manage the data ourselves and not rely on loaders.

Loaders work well to retain the data when they are only loading one thing for a screen, but for paging they created all this hassle and the way they operate is still not well understood; The conclusion being that they did not operate as expected or our implementation is faulty which only becomes apparent in more advanced use cases.

To manage the data ourselves we are using a combination of bundles/retaining fragments while being careful to clean everything up properly in onDestroyView. We also make the loaders check whether our dataset already has the data when they perform their callback after rotation so we don't add the paged data twice to our dataset. Another alternative would be to use a singleton object.

Hope this helps someone else in the future.

I'm have been trying to fix this for a week now, do you have any example code i could see? Thanks!. — Agustin Alvarez, Jul 29 '14 at 21:50
I don't have code, but you could try https://stackoverflow.com/questions/7181526/example-of-implementing-parcelable. Essentially just using asynctaskloader to get the data and store it in a parcel-able initially, then ignoring asynctaskloader on subsequent callbacks. The parcelable is then used for normal lifecycle conditions. — Zachary Moshansky, Jul 29 '14 at 22:51

How Does AsyncTaskLoader Cache Data?

1 Answers1