Wednesday, May 20, 2009

Observer Pattern using Closures

I have been working on a small Swing application. Its purpose is a batch download of various items that you select in the GUI. I only discovered Griffon after i had already begun and since it is just one screen, i decided to stay away from it for now. So, once i had the UI built (quite painful as it was a first foray into Swing for me, but that is Java's fault and not Groovy. Perhaps more on that in a separate post) and it was time to launch a thread and get updates from the thread to put in the text box in my application. In Java 6 there is a new class, SwingWorker to deal with this in an elegant way (see here for a demo of how to use it). However, with no inner classes in Groovy, this did not seem like it would work. But, in essence the closure has the power of the inner class since it has access to all the members of the class, so this seemed like way to go. And here it is

So, my worker class has the following:

private List closureList = []

public void addObserver(Closure c) {
    closureList += c
}

public void removeObserver(Closure c) {
   closureList -= c;
}

private void notifyObservers(String fileName, DownloadStatus status) {
   for (c in closureList) {
      c.call(itemName status)
   }
}


and the GUI class has following closure defined.

def guiUpdater = {String filename, DownloadStatus status ->
    swing.edt {
       if (status == DownloadStatus.COMPLETE) {
         resultsTextArea.append("Download of ${filename} completed\n")
       }
    }
}

Notice how in my closure i still need to use the swing event dispatch closure for the updates.

Tuesday, May 19, 2009

Let's get started

Even though I put a little blurb about the blog on the side, I figured I would still get started with a blog introduction. As a java programmer over the past few years, I have started dabbling with Groovy (and Grails as well, though less due to my lesser focus on GUI) and have looked for any possible reason to write tools in groovy. That is the reason I added it to the name of the blog as I figure at this point in time, my posts will probably gravitate more to the groovy world, so why not use the double meaning in the name.

A colleague of mine has commented that documentation of groovy is lacking. I think the problem is that many of the examples are simplistic, and for us java programmers what we are looking to learn is "what is the groovy way of doing things" and the ideas are not easily expanded to a more complex problem. This is further exacerbated by it being a scripting language, so the code complete will usually not provide the answers. Instead you will be looking around to try to figure out "what are the parameters i get in this closure?" or similar issues.

I find that i actually burn a lot of time on this, so developing in groovy has been slow, as my goal not to see Java code with a .groovy extension. In the end, i am usually quite satisfied with the results and am impressed with the readibility of this more concise code. And of course the next time i need to something it goes MUCH faster and it quite elegant!

So, i figured i would try to give back and help out with some of what i have done, providing the perspective of a relative newcomer to Groovy.

Hope you enjoy.