BerrySync: How fetcher gets it done, thread pooling

A Little Bit Of Background
I designed My fetcher library to have modules, these house the logic for the various steps I would need to perform. The fetcher itself links up the modules and goes from a url to a usable object for BerrySync.

One of the more troublesome modules was the Smuggler, I originally designed smuggler to do the network scheduling for fetcher then Smugglers worker thread would perform the actual connections, making the operation non-blocking(which is important for a good user experience!).

Now
I was forced to change the design, because the data parsing and decryption had to moved off the main thread. To facilitate this I gave Fetcher its own internal work Queue, with the smuggler still scheduling the network connections this time using Fetchers new and improved .invokeLater(runnable r) method!

public void invokeLater(Runnable work){
_queue.enQueue(work);
}
private final class WorkQueue {
        private Node _head;
        private Node _tail;
        private QueueWorker[] _worker;
        public WorkQueue(){...} 
        public synchronized void enQueue(Runnable data) {...}
        private synchronized Runnable deQueue() 

throws InterruptedException{...}
        private final class QueueWorker extends Thread {
            public void run() {
                Runnable work = null;
                while (true) {
                    try {
                        work = deQueue();
                        work.run();
                    }
                    catch (InterruptedException ignored) {}
                }
            }
        }
    } 

I'm using the runnable interface to formalize how this thread can 'run' your work. The commented out methods just show a simple queue linked list data structure.

Tune In Next Time
In the next instalment I'll tell you all about how I'm tracking down an elusive decryption bug with sync data on the BlackBerry!