Evan Summers's Blog

Enhanced DTs Extract 1: Progress Dialog Worker Preview

Here is an extract from an upcoming article, called "Enhanced DTs" about EDT "boilerplate" programming. It starts off looking at moving your boilerplate sideways into a separate class, and then ends off using CGLIB's interceptor mechanism (which CGLIB calls an "enchancer," hence the name of the article). On the way, we explore some other interesting EDT stuff like Foxtrot.

So anyway, this blog is an extract which is a preview - can you get any more noncommital than that?!

extract().start()

In addition to the standard SwingWorker we know and love, other convenient workers built on this are popping up, eg. BackgroundWorker in "Swing and Non Blocking JAX-WS", and Task in Hans Muller's JavaOne2006 JSR296 slides.

Richard Bair's Web Swinging presents SwingX-WS, a beautiful and convenient API for Swing clients to access webservices - and plain old websites, eg. to do some screen scraping, data mining, or whatever. If you haven't read that article yet, drop everything right now! Seriously! They have even implemented XmlHttpRequest for Swing clients, with an onReady listener. It's seriously awesome.

When accessing resources and services over the network, especially the internet, but actually any network, then background threading becomes a necessity, ie. using SwingWorker. One can automate this, eg. SwingX-WS will send the XmlHttpRequest in a background worker, which later fires an onReadyState event to be PropertyChangeListener, in the EDT.

But while our long tasks are running, what should we be doing, or more likely not allowing? For instance, the button that launched that task should probably be disabled. Because for example, hitting the "Get New Messages" button repeatedly in rapid succession doesn't really speed up the process of getting new messages from the email server (apparently).

Maybe we want to block the whole application, or at least the current panel, eg. using a modal dialog, or glass pane, while that task is executing. We might want to support a progress bar, and a cancel button. (See Kirill's great looking "progress glasspane" on flamingo.dev.java.net.)

So maybe we want some enchanced SwingWorker's at our disposal to drop into our code, as in the following example, which uses an enhanced worker of the blocking (modal) dialog variety, with a progress bar built-in for added convenience.

    protected void refresh() {
        refreshButton.setEnabled(false);
        try {
            DProgressWorker<ListModel, String> worker = new DProgressWorker(
                    new DDefaultProgressDialog(frame, "Simulating long task", true)) {
                protected Object doInBackground() throws Exception {
                    for (int i = 50; i < 100; i++) {
                        taskProgress(i);
                        if (i%10 == 1) taskInfo(Level.INFO, "Mmmmm.... " + i + "st donut");
                        Thread.sleep(50);
                    }
                    return new DefaultListModel();
                }
            };
            ListModel listModel = worker.get();
        } catch (DCancelledException e) {
            logger.warning(e);
        } catch (Throwable e) {
            dialogHelper.showExceptionDialog(e, null);
        } finally {
            refreshButton.setEnabled(true);            
        }
    }
}

I'll leave the blow-by-blow discussion of its implementation for a follow-up article, but here is a sneak preview...

(Progress Worker Demo, 110k/440k, unsandboxed, Java5)

You'll see that we introduce a "task listener" with which we construct our "progress worker." The worker publishes its current progress to the task listener, which in this example is a dialog with a progress bar and what-not.

Here is a screenshot of the demo running.

The next part of this "mini-series" will look at using this progress worker in a nonblocking fashion, where it publishes the progress to a status "mini-bar" at the bottom of the frame.

postscript()

Incidently i've been evolving a GUI "framework" which i'm using for these WebStart demos, and writing an article called GooeyBeans, with some beans binding and configuration and what-not. I did a bunch of stuff yesterday till all hours which got me to waking up this morning realising that so much of that software and article is actually rubbish. Gutting. But i am happy that it's gonna be much better than it is. That's what R&D is all about, making rubbish so that you don't make rubbish.

So i've renamed that article to "Squashed Gooey Beans," which is like, squashed and deprecrated, and not gonna be "published." It's on quitegooey.dev.java.net but please don't read it. I'm gonna rehash it, but hopefully not re-hash it, if you know what i mean. No, not hashish, i mean "making a hash of it."

Firstly i'm gonna make it a toolbag of toolkits rather than a "framework." Safer that way. Better that way. More application classes, but less smoke and mirrors aka reflection in the toolkit. That's why i'm happy that i'm breaking up this Enhanced DTs article into a mini-series, because that was also starting to look like an article to be renamed "Squashed DTs" at a later stage.

Funnily enough i realised last week that quitewriter was rubbish too. Anyway, i've redone quitewriter as quitehyper.dev.java.net and now i'm happy with that, very very happy in fact. Cos its so nice an' minimal, like... Mmmmm... crumpled up cookie thingies.

Comments

• After following your advances, I was looking forward to your framework. I'd like to know more about why you are choosing the "bag of tools" route and what paths you aren't going down (the reflection stuff). Interesting, keep up the awesome work!

  Posted by: michaelbushe on October 25, 2006 at 07:37 PM

• 
  Hi Michael! Thanks for your kind words.

  Writing an integrated framework where everything is tightly coupled,
  decreases its general usefulness. If it's a bag of tools, then different people can pick and choose which tool(s) they might or might not want to use, to give them some added convenience in some situtations, where it works for them. Hey, I think i'm quoting this verbatim from what someone else said? Cos it's sounds very familiar like deja vu or something? Yes, i think from a recent Hans Muller interview!?

  Also from an article-writing side, one should be able to explain and demonstrate individual aspects of the framework in isolation, as indendently useful toolkits, eg. beans binding, actions, and what-have-you. Because if you can't explain the software to someone in byte-size chunks that they can play with and understand, then that also decreases its general usefulness.

  So i want to try to separate the "framework" into more discrete toolkits, that can be used on their own. For instance maybe you want to construct a panel using Matisse, but matisse doesn't have beans binding (yet), so you want to use binding for that, ie. Presentation Model pattern - which i love, especially now that i know what it's called :)

  Actually quitegooey just started for dinky webstart demos, then i thought to use it as experimental (minimal) framework - an R&D exercise actually, to keep me on my toes and able to contribute to the discussions on JSR295 and 296. Writing articles is for me a design exercise. I find when i write articles, i'm standing back and can spot design flaws and see areas for improvement. So the writing process for me is a most important reflective design exercise.

  On the issue of using less reflection. I have a love-hate relationship with reflection, and with annotations. It's so tempting and easy to overuse these shiny things. So finding the balance is hard. I think i've found a better balance in the past few days, and i'll be writing it up of course, and publishing it very soon, in byte size chunks :)

  The other difficult balance, is trying the keep the application code more concise, more straighforward, and more agile (to changing domain requirements, and refactoring) - vs the same thing with the framework classes - which maybe we should call a convenience library that gets used by most of application classes, to keep them agile from a domain/business/logic programming perspective.

  At the same time, my personal silver bullet is that the laws of um, physics, or the theory of complex systems or something, dictate that it's logical that the complexity of a class and its methods can only be reduced by increasing the number of classes (and/or methods), if mass (functionality) aint gonna be destroyed!?

  So i've decided to bite that bullet and increase the number of classes, and use reflection and annotations in hopefully a more balanced way, to drastically simplify the framework classes (if not the application class count), to reduce the corresponding magic happening behind the scenes, and simplify the (individual) application classes, while still keeping them refactorable. In short, to find beauty in simplicity.

  Most programmers aren't gonna like it (more classes), and i don't like it much (yet), but i do believe in simplicity and clarity, all round, with no magic black boxes. I want an application which is totally recognisable as a traditional Swing application, where the "framework"
  just smooths over some rough edges eg. actions, configuration, and beans binding to enable presentation model pattern.

  The other crucial issue for me is toolability and refactoring. I mean the basic IDE stuff like auto-completion, renaming, and navigating code. I gotta have it! So i really don't like string references, and i liked annotations as a way to get around that. But i lost my balance there i think, and i'm trying to strike a new balance (this week).
  

  Posted by: evanx on October 26, 2006 at 05:01 AM

• I revised (and reformatted) the above article, see https://aptframework.dev.java.net/edt/progressWorker.html

  Posted by: evanx on December 06, 2006 at 01:48 AM

This work is licensed under a Creative Commons License.