Meaningless Drivel is fun!*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes FBNX: Gui and Threads, asynchronous Swing action execution and GUI updating. Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "FBNX: Gui and Threads, asynchronous Swing action execution and GUI updating." Watch "FBNX: Gui and Threads, asynchronous Swing action execution and GUI updating." New topic
Author

FBNX: Gui and Threads, asynchronous Swing action execution and GUI updating.

Klaas van Gelder
Ranch Hand

Joined: Jul 08, 2004
Posts: 100
Hi all,
Although my application already works fine, after reading some discussions on this form I am wondering if my GUI will pass the critics...

For the custom actions ((dis)connecting, booking, searching), I use Swing actions in which the actionPerformed method calls an operation on the Controller.
If the Controller operation succeeds, it calls notifyObservers on the model. And as the View is registered as an observer of the Model, the update() method on the View is called, which refreshes the View.

So far so good. But we are talking here about synchronous invocation of Controller operations. If an operation takes a longer time (as we may expect of all remote calls), the EventDispatchThread handling the actionPerformed method will spent too much time executing our action, resulting in freezing of the GUI.

We may wonder whether this is a problem, or if Sun expects us to address this pretty advanced item...
Some on this forum, however, have the opinion that all potentially longer Swing operations should be called asynchronously by spawning a separate thread. And maybe they are right.... !?

Suppose we do so. In my experimental code, I have implemented the actionPerformed method in my FbnAbstractAction class as follows:


and the callAsynchronousTask() method is of course implemented in the concrete XxxxxAction classes.
This works, but how about updating the GUI ? This happens now inside the controller methods called by the concrete implementation of callAsynchronousTask.

So:
-Is is a good idea to use asynchronous execution of Swing actions ?
-Should we use invokeLater to update the Gui ?
-If so, can we still update the Gui by calling update() from the Model ? Or do we need to perform the update inside the Swing actions ?
-Isn't it better to just let the GUI freeze shile executing an action ? None of the actions (connecting, searching, booking...) will ever be executed concurrently by one client.

This is my last big issue prior to submitment. But a iam afraid to lose main point (or fail !) by not handling Swing-multithreading correctly.

Please who can make thing a bit more clear... ?

Regards, Klaas

[ September 30, 2004: Message edited by: Klaas van Gelder ]
[ September 30, 2004: Message edited by: Klaas van Gelder ]

"What you don't know, can't help you"
SCJP (81%), SCWCD (81%), SCJD (354/400), SCBCD (85%)
Anton Golovin
Ranch Hand

Joined: Jul 02, 2004
Posts: 476
Hi, Klaas. My GUI is registered as the listener for its own events and basically handles them within the class. The controller provides its methods but does not handle anything. Rather, it stands between the GUI and the data model.

My GUI is not multi-threaded because it is outside the scope of the assignment.

I am sure that this decision will not fail the assignment if documented.


Anton Golovin (anton.golovin@gmail.com) SCJP, SCJD, SCBCD, SCWCD, OCEJWSD, SCEA/OCMJEA [JEE certs from Sun/Oracle]
Klaas van Gelder
Ranch Hand

Joined: Jul 08, 2004
Posts: 100
OK, lets assume that we dont need to call controller operations asynchronously.

You say that you dont update the View from the Model, but from within the actions itself. THat is very well possible, I suppose.
I choosed to register the View as an observer to the Model. When the model calls notifyObservers, all its observers are updated !
In our case, there is of course only one observer. And it is very unlikely that more observers (views)will be used at the same time !
So your solution sounds ok to me. But i am not sure whether it conforms to MVC "best practices"... :-)

In your case, you update the view from within your actions, which are performed my the EventDispatchThread. So you perform your updates from this thread, which is OK.
In my case, the update is carried out in the update method (inherited from the Observer interface) in my SwingView class.
I doubt whether it is still the EventDispatchThread who performs this method. If not, maybe i should use invokeLater to update the view.
Added later: I checked it out by printing Thread.currentThread().getClass().getName(), and this is still the EventDispatchThread.
So i suppose i can update the gui without invokeLater here...


Here my Threads/Swing knowledge leaves me alone... :-( who can help ?

Regards, Klaas
[ September 30, 2004: Message edited by: Klaas van Gelder ]
peter wooster
Ranch Hand

Joined: Jun 13, 2004
Posts: 1033
Originally posted by Klaas van Gelder:
OK, lets assume that we dont need to call controller operations asynchronously.

You say that you dont update the View from the Model, but from within the actions itself. THat is very well possible, I suppose.
I choosed to register the View as an observer to the Model. When the model calls notifyObservers, all its observers are updated !
In our case, there is of course only one observer. And it is very unlikely that more observers (views)will be used at the same time !
So your solution sounds ok to me. But i am not sure whether it conforms to MVC "best practices"... :-)

In your case, you update the view from within your actions, which are performed my the EventDispatchThread. So you perform your updates from this thread, which is OK.
In my case, the update is carried out in the update method (inherited from the Observer interface) in my SwingView class.
I doubt whether it is still the EventDispatchThread who performs this method. If not, maybe i should use invokeLater to update the view.
Added later: I checked it out by printing Thread.currentThread().getClass().getName(), and this is still the EventDispatchThread.
So i suppose i can update the gui without invokeLater here...


Here my Threads/Swing knowledge leaves me alone... :-( who can help ?

Regards, Klaas

[ September 30, 2004: Message edited by: Klaas van Gelder ]


invokeLater is useful for two things, the obvious one is getting a GUI update to occur on the EDT when your code is running on another thread, the other use is to prevent recursion by scheduling another task on the EDT even though you are already on the EDT.
Klaas van Gelder
Ranch Hand

Joined: Jul 08, 2004
Posts: 100

invokeLater is useful for two things, the obvious one is getting a GUI update to occur on the EDT when your code is running on another thread, the other use is to prevent recursion by scheduling another task on the EDT even though you are already on the EDT.


Please explain... I can grab the first reason, but not really the second. I want to update the GUI while I am in the EDT. In am not sure whether or not to use invokeLater here.
Greetz, Klaas
peter wooster
Ranch Hand

Joined: Jun 13, 2004
Posts: 1033
Originally posted by Klaas van Gelder:

Please explain... I can grab the first reason, but not really the second. I want to update the GUI while I am in the EDT. In am not sure whether or not to use invokeLater here.
Greetz, Klaas


Lets say that the Model calls the View which calls the Controller which calls the Model. If you do this in a single event, its possible that these recursive calls could build a very large stack or run for a long time before other events can be processed. If you make one of those calls using invokeLater, other events get a chance to run and the stack gets cut back.

The use of invokeLater will put a task on the Event Queue, this will get run in the Event Dispatch Thread when other tasks on that queue have completed. Its a bit like being sent to the back of the line.
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
 
subject: FBNX: Gui and Threads, asynchronous Swing action execution and GUI updating.