Questions: Swing GUI management from an external class and sharing logic with the user interface

Question

UPDATE: I am using Netbeans and Matise, and it is possible that it may be Matise, causing the problems described below.

UPDATE 2: Thanks to those who suggested constructive suggestions. After rewriting the code without the help of Matise, the answer suggested by Ignis worked as it described. I still don't know how the code generated by the Netbeans code generator intervened.

Although I programmed in Java for a while, I still have not programmed a GUI. I would like to control a certain part of my program from the outside (updating the jTextArea field with the output from an external source), without requiring any user actions to start displaying this output in jTextArea.

In particular, I want this output to start displaying at startup and start and stop depending on external conditions that have nothing to do with the graphical interface or what the user is doing. From what I understand so far, you can trigger such events through action listeners, but these action listeners assume that they are listening to user activity. If I have to use action listeners, is there a way to trick the GUI into thinking that user interaction has occurred or is there an easier way to achieve what I want to do?

In addition, I would like to know more about the best methods for separating GUI code from application logic. From the documents I came across, it seems that developing a GUI requires more of the messy integration of logic and user interface than, say, a web application where you can achieve complete separation. I would be very interested in any conclusions in this area.

Answer 1

No need to use listeners. GUI objects are similar to any other objects in the program, so in fact

• you can use the listener template in any part of the program, even if it is not associated with a graphical interface
• you can call GUI object methods whenever you want, at runtime, even if you do not connect any listeners to objects in the GUI.

The basic "rule" that you must follow is that every method call made on GUI objects must be triggered in the AWT event dispatch thread (yes, this is also true for Swing).

http://download.oracle.com/javase/tutorial/uiswing/concurrency/dispatch.html

Thus, you must wrap the code while accessing the GUI objects in

javax.swing.SwingUtilities.invokeLater( new Runnable() { ... } ) 

or

 javax.swing.SwingUtilities.invokeAndWait( new Runnable() { ... } ) 

http://download.oracle.com/javase/6/docs/api/javax/swing/SwingUtilities.html

---

O “Separate the GUI from the application logic”: google “MVC” or “model view controller”. This is the "standard" way to separate these things. It consists in making the GUI code (“view”) just a “facade” for the content (“model”). Another part of the application (the “controller”) creates and calls the desired model and view (it “controls” the execution of the program, or it should do it, therefore it is called the “controller”) and connects them to each other.

http://download.oracle.com/javase/tutorial/uiswing/components/model.html

For example, the JFoo class in the javax.swing package, which defines the Swing component, acts as a representation for one or more FooModel classes or interfaces defined either under javax.swing or with one of its subpackages. Your program will be a “controller” that will correctly create the representation and implementation of the model (which may be one of the default implementations found in those packages you mentioned, or a custom implementation defined among your custom packages in the program).

http://download.oracle.com/javase/1.4.2/docs/api/javax/swing/package-summary.html

Answer 2

This is a really good question, IMHO ... the one I asked a couple of years ago on the Sun Java forums (now basically non-existent, thanx for Oracle, a half-bloated package of febrile fiscal fascists).

At the beginning of putting order in kaos, which is your typical “first cut” GUI, Google for Swing MVC. The first article I read on this topic was the JavaWorld "MVC Meets Swing . " I was lucky because it explains the PROBLEMS and also offers reasonable solutions (with examples). Read this and go to Google for an “advanced reading” and hit us with any specific questions coming from this.

At the front of “simulated user activity” you have nothing to worry about ... you only need to observe the external conditions, say, you find that the local file has been updated (for example) and, in turn, raise a “notification to registered listeners (listeners) ... with the only difference being that you are implementing a “speaker” and “listener.” The Swings Listener interface can be reused for messaging (or not, at your discretion). Nothing complicated here.

The "uplift" of the "event" is absolutely straightforward. Basically, you just call the "EventHappened" method for each of the registered listeners. The only difficult bit concerns the “multithreading” that is inherent in all non-trivial Swing applications ... otherwise they will work like three-legged dogs, because EDT (google it) constantly does everything, and not just drawing and message broking (that is, for what it intended). (As Ignis said earlier) The SwingUtilies class provides several convenient invoke methods for "raising events" on EDT.

There is nothing special about Swing applications ... Swing has a pretty steep learning curve that everything, especially multithreading ... a topic that I had previously avoided, like a plague, like "too complicated for a modest brain like mine." Needless to say, it was an unreasonable fear. Even an old idiot like me can figure it out ... it will take more time, and all that.

Greetings. Whale.

Answer 3

This doesn't exactly answer your question, but you might be interested in using Netbeans to develop a Java GUI. You can use the GUI in Netbeans to develop a Java GUI.

Here's a good place to start - http://netbeans.org/kb/trails/matisse.html