We all know that Swing has some issues of devability (usability from the developer point of view) and completeness. Now, SWT combined with JFace has indeed been impressive in many regards. I believe the issue of completeness has been addressed nicely with SWT. As far as devability, I think the jury is still out because you could argue that you still have to interact with the API to set up components in a similar fashion to Swing.

I feel compelled to point out one important point, here. The SWT framework will not write your code for you. Nor is it going to design your application model. You still have to make your own breakfast because it’s not going to do it. As some of you may have found out, the JFace API provides some enhancements such as wizard dialogs and many other composite-type components for specific purposes. But if you don’t put thought into your application design, then using JFace really won’t help much. The biggest problems that I usually see plague desktop applications are in the overall design of an application.

Perceived Performance

Number one complaint in Java applications: “It takes too long to start up”. Back in 1.4 Java was making some great strides with startup. J2SE 5 is super fast and 6 is likely to scream. So why is everyone still complaining? Because we’ve forgotten that all-important facet of user interfaces: perceived performance.

Perceived Performance is the perception of application response to input. A lot of clients built today are parts of multi-tiered systems. They are but one layer that needs to communicate with data/services from another tier(s). Care must always be taken to make the client seem as fast as possible. The only way to do this is with Threads. I’m surprised by the number of people who are still concerned about using threads with Swing. Use care, of course, but percieved performance is achieved by multitasking. I will have another post soon devoted to the details of this topic and patterns to employ.

Invincible GUIs

Perceived performance absolutely will not be achieved effectively if your gui’s cannot stand on their own. Frame, Dialog, and Container composites should always be able to exist in instantiation without data. If you build it like that from the beginning you will find it much easier to handle the issues of perceived performance and as an added bonus you will likely find handling bad data (or the data extremities) much easier with this approach.

Data Access Layer

Both SWT and Swing require local models for operation. The concerns with the Look and Feel (most closely associated with the View) in Swing are alleviated with SWT but that doesn’t solve the problem of efficiently retrieving data from a data source. You need a clear data access layer (on your client, I mean). Design in such a way that the data can be retrieved without any gui involvement. In most cases, you should be able to write unit tests for all of your client data management that require no interaction with the client (this, by the way, will also remedy and allow you to isolate many problems associated with data interaction).

Action Encapsulation

Both Swing and SWT support the idea of Actions but they don’t force you to use them correctly. Individual units of application functionality should be encapsulated using your API’s respective command pattern for functional event handling. This allows your code to be clean; you can employ abstract behavior; you can control all widgets using a particular action. You have the foundation to be creative and build coherent (read: simple) sophistication. But just using plain event listeners for all widget event handling will be the root of many problems for you.

There are many issues of which a desktop application architect needs to be aware. These are some of the basic issues but there are other issues as well. SWT can resolve some issues for us, without question. But it doesn’t get anyone off the hook of designing a well-thought-out application.

Tags: eclipse, java, swing, swt, ui