• Post Reply Bookmark Topic Watch Topic
  • New Topic

A doubt about SwingWorker and when they should be used.  RSS feed

 
Claude Moore
Ranch Hand
Posts: 862
8
IBM DB2 Java Netbeans IDE
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi folks,

I used to use SwingWorker in a swing based application to execute some tasks that, being long lasting ones, I executed as background tasks. With respect to SwingWorker I used to create an anonymous SwingWorker instance, write an doBackground() method and put there all my background task logic. The main problem is that I realized after that I put event updating gui code in doBackground() method, which IS an error because I may cause EDT lock (as far as I understood).

Ok, I'll fix this problem but reading about SwingWorker I read that it should be used for any long-running task, to make GUI responsive. In a lot of GUI-events related methods (I mean methods which handle user's click on a JButton, or a selection in a JComboBox for example) I call a remote service method (exposed via EJB). These businesse methods may required a given amount of time to be performed (generally under a couple of seconds). With try - catch - finally usage I'm able to set a waiting cursor until remote method returns to the caller, and restore default cursor when execution is done, but I wonder if this approach may
create problems with EDT (I mean: to hung EDT) , and, if the answer is yes, if I need to isolate from EDT any remote call by using a SwingWorker.

Any help is really appreciated.

 
Rob Spoor
Sheriff
Posts: 20903
81
Chrome Eclipse IDE Java Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The normal way is to use 2-3 extra methods: publish, process and optionally done.

publish can be called within doInBackground. Anything you publish (limited to the generic type) will, at some point in time, be sent to process. Since process is executed on the EDT, you can interact with your user interface without any problems. The only thing you need to be careful about is that the arguments to several publish calls may be collected for one single process call. Don't assume that process is called immediately after publish.

done is called on the EDT after doInBackground finished, so you can use that to do some after-work user interface interaction (like possibly re-enabling GUI controls you have disabled just before the SwingWorker started).

 
Claude Moore
Ranch Hand
Posts: 862
8
IBM DB2 Java Netbeans IDE
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks Rob for your answer.... anyway, there's still a thing I can't understand: should I use SwingWorker always, when I have to interact with the remote server ?
 
Rob Spoor
Sheriff
Posts: 20903
81
Chrome Eclipse IDE Java Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Whenever you need to do something in your Swing application that takes longer than a few milliseconds (i.e. that would block your UI if executed on the EDT), it should be executed on a thread that is not the EDT. A SwingWorker is one of the easier ways to do this, but a simple thread could also be used. In that case you can make life a bit easier by using a SecondaryLoop.
 
Claude Moore
Ranch Hand
Posts: 862
8
IBM DB2 Java Netbeans IDE
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks again.... even if I have to admit that I think it's really really unpractical to recur to a SwingWorker every time you need to perform something important in terms of time consumed. For example, even opening a JDialog by pressing a JButton may be "time consuming" if the invoked JDialog requires a quite complex initialization - let's suppose to have a JDialog which executes a query and display its results.
 
Rob Spoor
Sheriff
Posts: 20903
81
Chrome Eclipse IDE Java Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
That sounds like a case for SwingWorker - calculate the query results in doInBackground and display the dialog in done.
 
Claude Moore
Ranch Hand
Posts: 862
8
IBM DB2 Java Netbeans IDE
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Rob, I really don't want to bother you...but.. What are the risks associated with not using SwingWorker in such cases? An un responsive GUI is what i want - user must wait until method finishes, bit i don't want a lock in EDT which blocks forever my application.
 
Rob Spoor
Sheriff
Posts: 20903
81
Chrome Eclipse IDE Java Windows
  • Likes 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You don't want to block your GUI, you want to block input to your GUI. If the entire GUI blocks, that also blocks repaints. Switch to another window, switch back - it looks horrible.

So that's what I usually do - disable all input controls, then re-enable them when done.
 
Claude Moore
Ranch Hand
Posts: 862
8
IBM DB2 Java Netbeans IDE
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks man for your answer.
 
Rob Spoor
Sheriff
Posts: 20903
81
Chrome Eclipse IDE Java Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You're welcome
 
Richard Tookey
Bartender
Posts: 1166
17
Java Linux Netbeans IDE
  • Likes 3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Rob Spoor wrote:

So that's what I usually do - disable all input controls, then re-enable them when done.


I use a glass pane to disable all inputs - see http://docs.oracle.com/javase/tutorial/uiswing/components/rootpane.html .
 
Claude Moore
Ranch Hand
Posts: 862
8
IBM DB2 Java Netbeans IDE
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
That would be a good approach, especially if your GUI has a lot of reactive components - buttons, combo and so on.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!