So far things are good with the new AudioMan architecture. I've taken playlists out of the picture to simplify the application while I play with SWT TableViewers. If you download the latest developer build that I released today you'll notice that the UI is much more responsive, owing to the fact that I now spawn asynchronous threads for the two longest running operations; Include File and Include Directory.

The Include Directory operation has no progress bar yet but I do plan to use one. For now the UI just sits there (though it's not frozen, you can still use it and browse the collection). I would like to allow the user to use the GUI while the include operations are taking place because they can be quite long. What I would like to do is use the status bar at the bottom to show the include progress and songs will be added to the model as they are included.

Another thing you'll notice is that the models are never cleared -- entries are added and removed as needed. If you add a few hundred songs and browse around, the time it takes to reload the All Artists track list is quite long as is the time to filter down to a specific artist again from the All Artists list. Though the UI effect is pretty neat -- seeing the items added and removed -- this is not the response we want.

The reason why it's doing that is because I set the TableViewer content provider's pointer to the model once (setInput()) and as I mentioned before, add and remove records as needed. The call to the database/repository runs asynchronously in its own thread, requesting the tracks that match the what the user wants (artist, album) loading them into the model and then finally removing the ones that don't match.

Instead what I think I will do is every time the user changes the artist or album I will make new models with the returned artists, albums and tracks (think recordsets) and use the content providers' setInput() method to swap the views' model listeners from the old models to the new models. Then the change in the UI will appear to be (in theory, hopefully) instantaneous, instead of the way it is now where you can see the items being added and removed.

Given that the call to the controller will be in its own thread, when the database/repository returns with the recordsets (they are arrays, but the analogy is helpful) I can construct the new models in the thread but I still need to call the content providers' setInput() method from the SWT thread. As mentioned in my previous post, all SWT calls must be done with the SWT thread (or threads maybe, I'm not sure. I've read that Swing supports more than one UI thread so maybe SWT does too).

Then the user interface will have to be notified asynchronously when the controller has loaded the new models and also given pointers to these new models. That can be done two ways: by registering a listener with the controller or by passing a handler as a parameter which implements the Runnable interface, which is executed when the models are ready. The handler option is what's known as the Gang of Four Command pattern, which is like passing a function pointer in C++ as a callback method.

Registering listeners is useful when you have more than one thing interested in being notified. In this case, the only thing that needs to be notified when the new models are ready is the view (GUI) so the overhead of registering and keep track of listeners is unnecessary though the architecture might be easier to grok. For now I will use the Command pattern with the Runnable parameter and see how well that works.

I am most interested to see if using setInput() with the new models will result in more instantaneous loading of the track list when the artist or album is switched. There could be a long delay extracting an Object array from a large model in the getElements() method, which is called by setInput() when there is a model change. Storing the models as arrays isn't an option because they have to be able to grow and shink. The conversion from collection to array has to happen.

By the way, Allen Holub's book Taming Java Threads is quite good. He gets into the details about how Java threads are (what I would describe as) a leaky abstraction (*cough*deprecated methods*cough*), especially from platform to platform. It's particularly good with the technical details of thread safety, which is exactly what I was looking for. It's a relatively old book though (2000) and that makes me wonder how much the virtual machine implementations have changed with regard to threading since then (approx Java VM 1.2).