Java AWT/SWT/Swing: How to plan a GUI?

Question

I\'ve already realized some applications with a small graphical user interface. Nothing complex, but I\'ve encountered several problems that components aren\'t displayed or

Answer 1

I would suggest you to use netbeans for GUI development in AWT/SWING.

Regards, Sameer

Answer 2

NetBeans might the best option for building GUI in WYSIWYG manner but many java developers write their GUI by hands, as it is not that difficult. Care about the thickness of your borders and gaps between your controls and you're ok :)

Answer 3

I'm not a big fan of GUI builders: They typically autogenerate bucket-loads of code that then locks in your whole development team to using one IDE. Also, this code is often unreadable (check the code generated when using Matisse under Netbeans).

My recommendations for GUI design / debugging would be:

• Add a main method to each panel (or "top-level" component) implementation, allowing other developers to easily determine what a component looks like.
• Favour the use of Actions over ActionListeners and register these actions with each JComponent's ActionMap. This allows them to be "extracted" and added to other parts of the UI (e.g. JToolBar) whilst still having their state controlled by the "owning" JComponent (i.e. loose coupling).
• Use assert to ensure that all UI component modifications are occurring on the Event Dispatch thread; e.g. assert SwingUtilities.isEventDispatchThread().
• To debug strange layout behaviour consider painting a component's background in red!
• Centralise the capturing and reporting of workflow events and exceptions. For example, I typically implement a TaskManager class that is registered with my UI's status bar. Any background processing (performed within SwingWorkers) is passed a handle to a Task created by the TaskManager. Interracting with the Task (by calling setDescription(String), setThrowable(Throwable), cancel()) causes the status bar to be updated. It also causes the glass pane to be displayed for "global" tasks ... but this is all decoupled / hidden from the individual SwingWorkers.
• Do not use the Observer / Observable classes, but instead favour ChangeListener, PropertyChangeListener or your own custom listener implementation for propagating events. Observer passes an Object as it's event, forcing client code to check the type using instanceof and to perform downcasts, making code unreadable and making relationships between classes less clear.
• Favour the use of JTable over JList, even in situations where your table only has one column. JList has some nasty features in its API including the fact that you need to provide a prototype value for it to calculate its size correctly.
• Never use DefaultTableModel as it typically results in you storing your "model" data in two places: In your actual business objects and also within the 2D array that DefaultTableModel sits on. Instead, simply subclass AbstractTableModel - It's very easy to do this and means your implementation can simply delegate through to the data structure (e.g. List) storing your data.

Answer 4

Apart from tools discussion, just some ideas and thoughts

1. Before you touch the keyboard, draw the GUI elements on paper. Like the classic storyboard used for video production. If you have customers, use the hand-drawn (!) designs to communicate the ideas (.. just read, that you already plan on paper)
2. Plan to implement a model-view-controller (MVC) or model-view-presenter pattern
3. Databinding is a great technique to consider. It guarantees synchronisation between your model (data) and the view (GUI) and offers input validation, on-the-fly conversion and many more useful things (Provided the link for JFace databinding, but I'm sure, there are other frameworks for Swing/AWT as well)

Answer 5

I'm one of those archaic dudes who do GUI layout by hand. I'm also not afraid of the infamous GridBagLayout!

I keep things simple for myself by emulating the coding standard used by Visual Age, years ago: I use a lot of JPanels to organize parts of the GUI, and each one gets its own makeXXX() method to create it, lay it out and return it to a a parent panel or the constructor. That way, each makeXXX only has to concentrate on a small part of the whole works.

Some components need to be accessible by various instance methods; I declare those as instance fields. The other stuff, that's just decoration or layout, need not be exposed outside the makeXXX methods.

That's mostly it. Works for me.

Answer 6

Do it by hand. GUI builders aren't good unless you have the 'partial class' concept in C#, and even then they often cause more problems than they solve. Use the GUI builder tools to make a prototype - sure, but not for production code.

Also, another little trick I've used over the years to good effect when trying to debug layout or "which panel am I really seeing here" problems is to give each 'container' panel a really garish background color (yellow, blue, etc). Something obvious enough that you'll see it even if it's only one pixel wide.

And my favorite layout for simple dialogs is BoxLayout. It's not great, you have to write a lot of boilerplate, but at least it generally works the way you would expect it to in your head. Don't overthink layouts until you have to.