« Groovy Faster than Ruby? Apparently. | Main | What an excellent idea... »

Greet - A Groovy Twitter Client

The demo application from the Groovy SwingBuilder Tech Session at JavaOne 2008 is now runnable via WebStart. (note to self, link to SDN site when the presentaiton goes live). The source code may also be browsed via FishEye. There are a couple of points I wish to call out that were touched on in the tech session:

Model View Controller Separation

The GUI has a firm model view controller separation. All of the Twitter API functionality is sequestered into the TwitterAPI.groovy class. No other class does network functionality. The GUI code is also handled separate from the controller. View.groovy is the main class, whereas a couple other classes (ScrollablePanel.groovy, RoundedPanel.groovy) are there to support the view portion. One other view class, TweetLine.groovy, handles the rendering of the individual tweet line (because I was not satisfied with JList). Finally there is the controller class, Greet.groovy. In addition to the main method all Swing events are dispatched to the various controller methods. State variables are also kept here.

Use of @Bindable and bind()

A lot of the glue code to manage visual state with the controller has been automated because of the new @Bindable annotation in Groovy 1.6. This allows me to send notices that the view shouldn't be accepting updates and also notify the view that the backing data model has changed. Adding these hooks by hand would add at least 100-200 lines to the application and would also introduce repetitive code that is prone to cut and paste errors. The view code uses the bind() node to easily bind the values of the actions to relevant attributes.

Actions are your friends

Less of a Groovy call out and more of a Swing call out. Use actions, actions are your friends. All of the buttons, text lines, and list boxes are not hooked directly to the controller, but to the action. This causes all of the relevant controls to turn off when the action becomes unavailable, and is why the bind to enable occurs in the actions definition and not the control definitions.

Builder scripts are still Groovy Code

In line 142 to 147 of View.groovy I do a loop inside of a panel to add the tweet lines individually, calling out to the TweetLine.groovy script. This is perfectly legal in Groovy, since a builder is actually just executing closures and using meta-programming to intercept the method calls. It may look like a static declarative XML type file in most cases, but it doesn't have to. Especially with repeating elements, it's a great way to DRY out code.

The 'Dynamic Language' part is what makes it possible

The dynamic language aspect of Groovy code (and in particular the Scripts) is what allows for most of the magic to happen. It is essential to the builder pattern. You will also notice that both of the principal view scripts (View and TweetLine) don't create a SwingBuilder, or even imply that one exists. They also use variables that are not defined in the scope of their script (like the controller object and the tweet). This provides for a very subtle form of resource injection that requires no ceremony to access. If this were statically typed I would have to state somehow the methods and fields the controller and tweet have, even if by simple type decleration. All of that formality is unneeded in this context.

So what is the future of Greet? I intend it to be one of a few marquee examples for a project I am attempting to get off of the ground with a few others, so the WebStart version may see some changes every once in a while. But that is also why I am a fan of the promise of WebStart (if not particular shipped versions), new versions can be distributed without the same ceremony as an installer.

Comments (11)

One small nitpick:

public static void main(String[] args) { ... }

should be:

static void main(args) { ... }

otherwise -- awesome app :)

(sorry if i offended you)

--rob

Danno Ferrin [TypeKey Profile Page]:

Actually, I shouldn't even have a main method in Greet.groovy, I should be launching it from a Groovy script. That is what Guillaume did to it for the script bowl. Application lifecycle is a slightly different issue than MVC controller functionality.

There's other things to tidy up as well, I'm sure there are some semi-colons as well in places I could get rid of them (old coding habits die hard).

yeah, kinda yeh =)

Sakuraba:

I love how the WebStart version just works out of the box... if only I could create a shortcut/drag the program into my Leopard dock or something like that.


what worked:
- retrieved friends
- sending a tweet

what didnt work:
- seeing my sended tweet
- seeing any tweets at all
- pretty much any item of the tabbar ;)

Please provide some "if(os == MacOSX)" magic to make it more native.

Danno Ferrin [TypeKey Profile Page]:

I had compiled the jar with a 1.6 JDK (for groovy it matters) The jar should be updated now. We'll get a chance to see how auto-update works.

Danno Ferrin [TypeKey Profile Page]:

Yes, you will need to go delete the files in Java Preferences (applicaitons/utilities/java/java 5.0/Java Preferences IIRC.) There are some JNLP tricks I am not taking advantage of to insure this doesn't happen.

Any instructions on how to build Greet from src?

Nevermind my silly questions...

Danno Ferrin:

Well.. the files referred to in this post live at http://svn.codehaus.org/groovy/trunk/groovy/modules/griffon/src/examples/greet/

Download all of the groovy files, compile them with Groovy 1.6-beta1, and run the greet.Greet java class.


However, Greet is evolving to become a marquee applicaiton for a new framework I am working on called griffon. It's not ready for mass consumption yet, but a cursory build instruction is available here

Tonći:

Hi,

I tried Greet by using this Web Start URl: http://dist.codehaus.org/griffon/samples/greet/greet.jnlp and it seems outdated. The app starts but logging in won't work, I see a message at the bottom: ``ParseException:Unparseable date: "Wed M``

Is a new version available which does work?

Danno Ferrin [TypeKey Profile Page]:

There is a version of greet running off of Griffon 0.1.0 (which is more current than the link in this blog entry).

http://dist.codehaus.org/griffon/samples/0.1.0/Greet/greet.jnlp

The error you post seems to be an issue with twitter's API. I don't have code to show an amputated robot when Twitter gives me bad data.

The link in your comment seems to be fine for me. You probobly caught twitter in the middle of a front end update roll-out.

Post a comment


About

This page contains a single entry from the blog posted on May 13, 2008 8:40 AM.

The previous post in this blog was Groovy Faster than Ruby? Apparently..

The next post in this blog is What an excellent idea....

Many more can be found on the main index page or by looking through the archives.

Powered by
Movable Type 3.33