tying back end to gui java

Question

I recently started to develop a GUI in Swing to put on top of a simple XMPP client i wrote in java using the Smack API. The problem im having is a matter of trying to figure out exactly how to transform button clicks to actions on the client without being forced to write spaghetti code to tie everything together.

Are there any examples/tutorials that you know of which will show more complex swing applications than "oo look i put a button on the screen"? Unfortunately my google-fu seems to only return countless variations of these simple entry level lessons. I would very gladly accept an opensource application you know of that i can research. Even just a topic such as "EventHandlers" to start with would be amazing.

I apologize for the vagueness of my question but i feel like at this point im just searching for symbols in google. (IE unless you already know what its called typing the symbol into google is useless). If i was unclear please mention where and i'll to my best to clarify. Thanks.

Answer 1

Learning how to use Swing is easy. Learning how to use Swing effectively is not as easy. It's one of those wicked problems where you have to get it wrong a few times first.

That said, two of the most important concepts I would recommend are proper use of the Action API and Swing concurrency. Using the Action API properly will allow you to keep your controller code modular, by defining actions that can be linked to any number of visual components. For example, you can associate the same action with a menu item, a button, or a keyboard shortcut. Using concurrency tricks such as SwingWorker allows you to do long-running tasks without freezing the user interface and without having to reinvent the wheel or manually manipulate different worker threads.

Another piece of general advice I would give is to study up on Model-View-Controller, as other posters have suggested (though technically Swing bundles the View and Controller together). Create models which represent the data you want the user to be able to manipulate and use your own custom events and listeners to pass that information to the view. In other words, don't be afraid to override EventObject to represent different changes in your application's state. This also lets you have a single model object (in your case, perhaps a contact list) that you can hook different views into, without having to change the underlying structure.

Oh, and another piece of fluff -- if your actions don't need to be reusable, a nice anonymous inner class derived from ActionListener is more readable than making the view class itself the ActionListener. Every time I see component.addActionListener(this) I shudder.

All that being said, the best way to learn is by doing, so go ahead and experiment, and figure out what strategies work for you.