What are your best Swing design patterns and tips?

Question

I'm writing a GUI for an application using Swing, and in the interests of code maintenance and readability, I want to follow a consistent pattern throughout the whole system.

Most of the articles and books (or at least book sections) that I've read appear to provide plenty of examples on how to create and arrange various components, but ignore the bigger picture of writing a full GUI.

What are your best tips for application GUI design, and what patterns do you follow when designing or refactoring a GUI application?

Solution 1

Use layout managers. You might think it's simpler just to position everything with hard coded positions now (especially if you use a graphical layout tool), but when it comes time to update the gui, or internationalize it, your successors will hate you. (Trust me on this, I was the guy saying to use the layout managers from the start, and the successor to the guy who ignored me.)

Solution 2

Never derive from JDialog, JFrame or JInternalFrame for defining your forms, dialogs...

Rather derive from JPanel. This will bring you the follwing advantages:

• possibility to later change from a JFrame to a JDialog for instance (because user changed his mind)
• you can reuse one panel instance from one JDialog to another (JDialog are generally not reusable because they are constructed with a reference to their "parent", a frame or another dialog)
• you can later on change replace JDialog with a more functional subclass from a 3rd-party framework.

Solution 3

Avoid using GUI layout designers (builders). Later on it will make your code much cleaner and easier to maintain.

Solution 4

I think a good working knowledge of concurrency is often understated. You really need to be familiar with Swing's threading policy and general synchronization techniques to build a responsive GUI and an efficient backend.

Solution 5

Avoid spawning too many threads when user clicks action button multiple times. Disable button on first click, spawn your action in background thread, and when done, enable button again. This may not be problem for short running tasks.

View more solutions

Comments

[Eddie]

It's true that if you start your GUI with a builder, you are pretty much committed to using that builder throughout the whole life of the GUI. This is sometimes acceptable, sometimes not.

[Marko]

Yes it's true. Different builders store metadata in different formats which are not mutually compatibel. The only exception is Instantiations Swing Designer which works with the code directly. All of them create code which is not meant to be edited by hand (unreadable) which will bite you later.

[Paul Tomblin]

Yes, SwingWorker is one of many ways to spawn off a thread.

[Rémi Vennereau]

I disagree. If you know Swing well any code generated by a GUI builder will be readable enough. Problem is that by using a GUI builder you will not get to know Swing well. Good separation is of course necessary.

[Rémi Vennereau]

Dont forget SwingUtilities invoker later if that thread needs to update the GUI afterwards :)

[Rémi Vennereau]

Along with this I would define a 'view' interface.

[Gary Kephart]

Take a look at FoxTrot: foxtrot.sourceforge.net

[Mot]

What should your 'view' interface do?

[Mot]

In your case it is obvious, because application != frame, but there are other examples, e.g. FooFrame extends BarFrame, where inheritance also is not appropriate, e.g. because they have too less in common.

[James P.]

WindowBuilder Pro does a good job with generated code. Check it out: developers.google.com/java-dev-tools/wbpro/?hl=fr