• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

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

 
Ranch Hand
Posts: 111
PHP Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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 ]
 
Ranch Hand
Posts: 531
1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Klaas van Gelder
Ranch Hand
Posts: 111
PHP Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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 ]
 
Ranch Hand
Posts: 1033
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 111
PHP Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator


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
Posts: 1033
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.
 
Politics is a circus designed to distract you from what is really going on. So is this tiny ad:
a bit of art, as a gift, the permaculture playing cards
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic