The Include Directory action in AudioMan can be quite a long operation. The way I do it now, the recursive crawler code goes into the directory recursively and finds all of the MP3 files and returns an array of tags at the end of the crawl. Then I iterate through this array of tags and add them to the repository one at a time.

There are problems with this approach though. Crawling through the directories takes much longer than adding a file to the repository, so the UI appears to do nothing for a long time and then is suddenly loaded with many songs. I could keep a count of found MP3 files in the status bar as I find them but all of the songs would still appear all at once in the end.

I also have to consider the TRM calculation for unique id's based on the audio I want to do later, which is long and requires a lot of I/O. I could do those after I've read all of the tags though (in the background) so that the user gets all of the tag information as soon as possible. This is the same way that Windows Explorer in Windows XP calculates the length of large movies, one at a time after the window appears. Once the TRM is calculated I only have to recalculate it if the file's last modified date changes. So it's expensive but not done very often.

A better option would be two threads: one crawling the directories and the other adding them to the repository as they are found. The second thread would give a handler to the first thread (using the Command pattern again) so it can tell the other thread when an MP3 file is found. Then the view will start updating immediately and the user will see new files added as the crawler finds them.

The problem with crawling a directory recursively is that you don't know how many files you'll find or how long it will take so a progress bar doesn't really fit. The user interface should give the user feedback some other way though. I could put the directory currently being looked at in the status bar but then they would just zip by. Same goes for the song filenames as I include them -- they would just go by too quickly for the user to read them.

On the other hand that's not really the point. The point is to let the user know that something is happening so they don't feel like the operation didn't work -- the UI needs to give feedback. Remember, when you do an include directory now you can still browse around and use the application. When you do a long include directory it seems as though nothing is happening until when much later a whole bunch of songs are added. To show the directory names in the status bar the UI will have to send a handler to the include directory operation to update the GUI using the SWT thread.

I also have to figure out why my Java directory crawling code is so slow. I've seen Windows programs like WinAmp (likely written in C++) crawl directories recursively much much faster. I wonder if it is a limitation of the Java VM or just the way my code is written.