Question

I’m currently using what I assume is a common pattern in Android, of fetching data from a network using various AsyncTasks, and updating a simple ArrayAdapter on completion using an interface callback mechanism.

cwac-endless is reasonably easy to plug in to add pagination type scrolling, aside from the fundamental issue that it assumes it will handle running the background task for you. Does this mean I basically have to rip up all my AsyncTask classes and associated interfaces, and move all the code from doInBackground into my EndlessAdapter’s cacheInBackground?

Most solutions I’ve tried seem to end up duplicating much of the code already in cwac-endless, so I feel there must be cleaner solution to using this adapter with an existing AsyncTask?

Answer 1

cwac-endless is reasonably easy to plug in to add pagination type scrolling, aside from the fundamental issue that it assumes it will handle running the background task for you

Handling “running the background task for you” is most of the point behind the adapter.

Does this mean I basically have to rip up all my AsyncTask classes and associated interfaces, and move all the code from doInBackground into my EndlessAdapter’s cacheInBackground?

If you wish to use EndlessAdapter as it stands, yes.

You are certainly welcome to grab the code, modify getView() to not use its own executeAsyncTask and AppendTask and replace that logic with your own. However, pretty much every line of code in AppendTask is necessary for EndlessAdapter to work. And I have no idea how any endless construct would work with “custom AsyncTasks” plural, as there has to be a clear end to the work so that we know to show the new rows in the list and get rid of the pending View. Hence, you would still need to designate some AsyncTask of yours as playing the role of AppendTask, doing everything that you are presently doing and all of the logic in AppendTask. Whether that is simpler than just using the existing EndlessAdapter code base, I cannot say, as I do not know your code.

I feel there must be cleaner solution to using this adapter with custom AsyncTasks?

You are the first person to ever raise the issue, and hence I have never considered it prior to typing in this answer. I will give it some thought and may try to do some refactoring to help with your scenario.