How to return ArrayList results from an IntentService

Question

I have an IntentService that loads up an ArrayList with data from a network source (AWS SDB tables). The ArrayList is in a global space -- accessible to both the calling Activity and the IntentService (like this: appState = ((App)getApplicationContext()) ). When the IntentService is done, it notifies the Activity through a ResultReceiver, and the Activity calls adapter.notifyDataChanged() to update the ListView.

This solution works most of the time, ... but it violates the rule that only the UI thread should make changes to data underlying a ListView. So as it is, I sometimes get an error: "The content of the adapter has changed but ListView did not receive a notification."

I think this must be a common situation. Please let me know if you have any suggestions or best practices for this problem. Here are three options I'm aware of:

1. Keep the IntentService , and have it store the results in another "working" ArrayList, also in the global space. When the result is ready, the IntentService calls the ResultReceiver (on the UI thread), which can then: a) copy the result to the ArrayList associated with the ListView, and b) call adapter.notifyDataChanged(). CONS: I don't like the idea of putting temp/working data in a global space, and copying the result list seems inefficient.

2. Keep the IntentService , and have it pass the results back through a bundle loaded with a ParcelableArrayList. CONS: I'm not sure if this approach would scale for very large result sets. It also requires copying the result list.

3. Switch to a Service which builds a local copy of the result list. Have the Activity directly access the address space of the Service in order to read the result list. CON: Still requires copying results to the ArrayList associated with the ListView.

Thank you.

Answer 1

I switched over to using Parcelable (ie, option 2 above), and it works fine now. I used the code from this accepted answer as a reference.

Still testing, but I'm pretty sure the change resolved the error I was getting by updating the adapter's underlying list off the UI thread. I have yet to try it for lists with > 100 elements, but so far so good. Thanks.