Question

I’m running into an IllegalStateException updating an underlying List to an Adapter (might be an ArrayAdapter or an extension of BaseAdapter, I don’t remember). I do not have or remember the text of the exception at the moment, but it says something to the effect of the List’s content changing without the Adapter having been notified of the change.

This List /may/ be updated from another thread other than the UI thread (main). After I update this list (adding an item), I call notifyDataSetChanged. The issue seems to be that the Adapter, or ListView attached to the Adapter attempts to update itself before this method is invoked. When this happens, the IllegalStateException is thrown.

If I set the ListView’s visibility to GONE before the update, then VISIBLE again, no error occurs. But this isn’t always practical.

I read somewhere that you cannot modify the underlying this from another thread–this would seem to limit an MVC pattern, as with this particular List, I want to add items from different threads. I assumed that as long as I called notifyDataSetChanged() I’d be safe–that the Adapter didn’t revisit the underlying List until this method was invoked but this doesn’t seem to be the case.

I suppose what I’m asking is, can it be safe to update the underlying List from threads other than the UI? Additionally, if I want to modify the data within an Adapter, do I modify the underlying List or the Adapter itself (via its add(), etc. methods). Modifying the data through the Adapter seems wrong.

I came across a thread on another site from someone who seems to be having a similar problem to mine: http://osdir.com/ml/Android-Developers/2010-04/msg01199.html (this is from where I grabbed the Visibility.GONE and .VISIBLE idea).

To give you a better idea of my particular problem, I’ll describe a bit of how my List, Adapter, etc. are set up.

I’ve an object named Queue that contains a LinkedList. Queue extends Observable, and when things are added to its internal list through its methods, I call setChanged() and notifyListeners(). This Queue object can have items added or removed from any number of threads.

I have a single “queue view” Activity that contains an Adapter. This Activity, in its onCreate() method, registers an Observer listener to my Queue object. In the Observer’s update() method I call notifyDataSetChanged() on the Adapter.

I added a lot of log output and determined that when this IllegalStateExcption occurs that my Observer callback was never invoked. So it’s as if the Adapter noticed the List’s change before the Observer had a chance to notify its Observers, and call my method to notify the Adapter that the contents had changed.

So I suppose what I’m asking is, is this a good way to rig-up an Adapter? Is this a problem because I’m updating the Adapter’s contents from a thread other than the UI thread? If this is the case, I may have a solution in mind (give the Queue object a Handler to the UI thread when it’s created, and make all List modifications using that Handler, but this seems improper).

I realize that this is a very open-ended post, but I’m a bit lost on this and would appreciate any comments on what I’ve written.

Answer 1

This List /may/ be updated from
another thread other than the UI
thread (main)

That won’t work.

I read somewhere that you cannot
modify the underlying this from
another thread–this would seem to
limit an MVC pattern, as with this
particular List, I want to add items
from different threads

MVC has nothing to do with threads.

can it be safe to update the
underlying List from threads other
than the UI?

No. Other threads can trigger updates to the adapter (e.g., via post()), but the updates themselves must be processed on the main application thread, for an adapter that is currently attached to a ListView.

Additionally, if I want to modify the
data within an Adapter, do I modify
the underlying List or the Adapter
itself (via its add(), etc. methods).
Modifying the data through the Adapter
seems wrong.

You modify your Adapter via the Adapter itself for ArrayAdapter. You modify your Adapter via the underlying database/content provider for CursorAdapter. Other adapters may vary.

I’ve an object named Queue that
contains a LinkedList. Queue extends
Observable, and when things are added
to its internal list through its
methods, I call setChanged() and
notifyListeners().

Have you considered using LinkedBlockingQueue, rather than implementing your own thread-safe Queue?

This Activity, in its onCreate()
method, registers an Observer listener
to my Queue object. In the Observer’s
update() method I call
notifyDataSetChanged() on the Adapter.

Adapters should call notifyDataSetChanged() on themselves (if the change is made by them) or have it called on them by the entity that is changing the data (e.g., a Cursor for a CursorAdapter). That is MVC. The Activity should neither know nor care when your data model changes.

So it’s as if the Adapter noticed the
List’s change before the Observer had
a chance to notify its Observers, and
call my method to notify the Adapter
that the contents had changed.

Possibly you are using an ArrayAdapter, in which case all this extra observer/notify stuff is getting in your way, since that’s handled for you. You just need to arrange to update the ArrayAdapter on the main application thread.

So I suppose what I’m asking is, is
this a good way to rig-up an Adapter?

Not particularly, IMHO.

Is this a problem because I’m updating
the Adapter’s contents from a thread
other than the UI thread?

If you aren’t forcing the updates back to the main application thread, this will eventually crash, once you clear up your other problems.

give the Queue object a Handler to the
UI thread when it’s created, and make
all List modifications using that
Handler, but this seems improper

You could use a Handler, or you could call post() on your attached ListView.

Off the cuff, I’d create a subclass of ArrayAdapter named ThreadSafeArrayAdapter and use it in place of Queue. ThreadSafeArrayAdapter replaces add(), insert(), and remove() with ones that have the superclass do its thing on the main application thread, via a Handler or post().