A Guide To The Future (Of Swing Applications)
I posited in my last blog that Swing application development is about to change for the better. A few years ago the topic of the Swing conversation shifted from the components to the applications. People were no longer just trying to wrap their heads around the toolkit, but instead they started to shift their effort to figuring out how to really write professional applications with this thing. This is a neccessary step in the maturation of any new technology. I'm not sure why it took so long for Swing to get there, but the happy point is that it finally did.
The result was that some new Swing components were created to fill some gaps in the toolkit and some best practices started to emerge. Heck, there even began to be a few books published that were not just guided tours of the Swing component library. People finally stopped feeling obligated to try and explain that Swing was based on a kind of modified MVC. Yes, yes, we get it, already. The view and controller are sort of combined...well except that there are these things called UI delegates that do control how the view is rendered - unless you override the paintComponent method, of course.
Oh, and there are defaults for the look and feel that may or may not be in effect because the programmer can override them by setting properties and, well, events can be kind of a pain to handle because you have to implement an ActionListener, or a MouseListener or WindowListener or ChangeListener or whatever, as an inner class. Or you can use an anonymous class if it's really just a small event handler but that makes your code look a little uglier. But there is an abstraction called Action that can make life a little easier for you in some situations. And threading? Don't even go there! Uhm...what was I saying again?
Oh yeah, as I was saying, I'm not sure why it took so long for the Swing community to move past that initial figure-out-the-toolkit stage. One of life's great mysteries, I guess.
But now we are finally ready to start looking at the bigger picture and answer the really interesting question: "So just what is the best way to actually write a Swing application?"
I claim that the appropriate answer to that question no longer begins with: "Well, there is this thing called a JFrame, see, and you need to be careful how you instantiate it - no, you really shouldn't just subclass it - there's this method called invokeLater and what you do is..."
So let's take a look at the things that will go into building tomorrow's professional Swing application. If I had to come up with the core technologies to base my next Swing application on, what would it look like? In one sense, the answer could be as simple as "just use Netbeans RCP." But what fun is that? So let's assume that the application's complexity or the developer's skill level makes the Netbeans RCP inappropriate. After all, there are whole classes of applications for which an RCP is overkill but they still have to look good and behave well on user's desktops. Rich Internet Applications, I'm looking at you.
Begin At The Beginning
Let's start simple. All good applications need a splash screen, right? A sweet little piece of eye candy to get things started. Well, thanks to the splash screen support in Java 6, this is now trivial for a Java app.
Alright, next we need some frameworks so that we can avoid the you-start-with-a-JFrame syndrome mentioned above. Well the Swing application framework and the new data binding framework (JSRs 296 and 295, respectively) fill this need. The app framework handles your application's infrastructure: resources, i18n, and actions. These two JSRs also make it easy to access data on a background thread and bind that data to components in your views.
But how do we create those views? Hand coding, you say? That is so 12 months ago. These days the tools are good enough that you don't have to spend all day writing that dialog panel that should only have taken 30 minutes. Still trying to make GridBagLayout work? You poor bastard. Stop! Netbeans has Matisse with it's support for GroupLayout. There is also JFormDesigner or Idea with support for JGoodies Forms. Life is too short to code your UIs by hand. These products make it almost trival to design complex panels. Doing the same with gridbag would be about as much fun as teaching preschool to teething toddlers.
A lot of real applications also need to interact with the user's desktop and perhaps launch the native email client or web browser. This can all be done in Java 6 now thanks to another recent addition.
All programs need a way to report errors to users. My experience is that most programs at some point have to work with dates as well. Swing doesn't have a nice solution for these, but there is always SwingX. Here are the date picker and error dialog from SwingX.
There are a lot of other components worth checking out in SwingX. JXTable and JXList are very nice replacements for Swing's JTable and JList, for example. My advice for getting started with SwingX is to skip right over the old out-of-date SwingX milestones and go download the latest weekly build. It is worth pointing out that SwingX is one of the projects of SwingLabs along with the a lot of other good stuff, some of which I'm going to write about below.
One big drawback of SwingX is that it is hard to get up to speed. The situation is improving with the recent changes in the project's infrastructure and the documentation is also improving. There are also plenty of good commercial components out there from vendors like JIDE and MiG.
Adding The Wow Factor
Adding that extra punch to an application is becoming the norm these days thanks to users whose expectations have been raised by flashy websites and slick Mac applications. This is a good thing. After all, putting in the "wow" is where most of the fun is! To easily add some sizzle to a Swing app, you will need to look at the Painter work being done in SwingX. Note that the latest painter work is just now being merged back into the main development trunk of SwingX. Isn't it fun to be on the bleeding edge of the future? And, of course, you will need the timing framework for all of the cool animation you have to put into your program.
Since we're talking about the future of Swing development here, there is also a new cross platform look and feel in the works that doesn't suck. It's called Nimbus.
Ok, so here is my list of technologies anyone starting a new Swing applications should check out:
- Splash screen support
- Swing application framework
- Beans binding
- Matisse GUI builder
- Desktop integration
- SwingX components and painters
- The timing framework
What did I miss? What technologies do you need to learn today to write the Swing applications of tomorrow?