aspose file tools*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes B&S: Multi threading, Swing, SwingWorker Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Spring in Action this week in the Spring forum!
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "B&S: Multi threading, Swing, SwingWorker" Watch "B&S: Multi threading, Swing, SwingWorker" New topic
Author

B&S: Multi threading, Swing, SwingWorker

Michal Charemza
Ranch Hand

Joined: Jul 13, 2004
Posts: 86
Hey,

I've just started designing my B&S assignment. I'm considering using multi threading in my GUI. That is, starting off a new thread to talk to the server. I have a question about this approach:


I've seen the class SwingWorker and it seems like a good idea (for a real world project at least) to use to start new threads. Specifically, the "finished" method that is run in the event dispatching thread once my new thread is finished, which I could use to update the GUI once talking to the server is finished. It seems like a really clean and organised way to write it.

I am worried that if I do write my own, my class will be too similar to Sun's. I mean, I want to write a good class, and if I see that Sun's does something a certain way, and I think "ah yes... that is a good way of doing that", and I write it that way, could I be accused of just using their code, and violating the spec "you must not submit any code that is not your own work"?


Michal

[ August 26, 2004: Message edited by: Michal Charemza ]
[ August 26, 2004: Message edited by: Michal Charemza ]
Anton Golovin
Ranch Hand

Joined: Jul 02, 2004
Posts: 476
IMHO, it's overcomplicating the assignment. My project will put up a modal info box, saying, that the system is working... it should not take that much time to get results back.


Anton Golovin (anton.golovin@gmail.com) SCJP, SCJD, SCBCD, SCWCD, OCEJWSD, SCEA/OCMJEA [JEE certs from Sun/Oracle]
Andrew Monkhouse
author and jackaroo
Marshal Commander

Joined: Mar 28, 2003
Posts: 11481
    
  94

Hi Michel,

Questions about the SwingWorker crop up often enough that I am tempted to add something to the FAQ about it. Usually the question being asked is whether it can be used directly though.

As developers, we are always going to be inspired by good code / good designs we have seen in the past (or at least, I hope that is the case - otherwise we are just going to continue reinventing the wheel). This is something we should embrace - if there is a good design, use it!

So don't worry about your code ending up similar to Sun's code - there are cases where this will happen even if you are unaware of it (especially for those people learning RMI for the first time, and using it in their assignments - their RMI implementation is going to be almost identical to the Sun tutorials ).

Others have done this in the past and passed, so this does not appear to be a problem.

Regards, Andrew


The Sun Certified Java Developer Exam with J2SE 5: paper version from Amazon, PDF from Apress, Online reference: Books 24x7 Personal blog
peter wooster
Ranch Hand

Joined: Jun 13, 2004
Posts: 1033
Originally posted by Michal Charemza:
I've seen the class SwingWorker and it seems like a good idea (for a real world project at least) to use to start new threads. Specifically, the "finished" method that is run in the event dispatching thread once my new thread is finished, which I could use to update the GUI once talking to the server is finished. It seems like a really clean and organised way to write it.

I am worried that if I do write my own, my class will be too similar to Sun's. I mean, I want to write a good class, and if I see that Sun's does something a certain way, and I think "ah yes... that is a good way of doing that", and I write it that way, could I be accused of just using their code, and violating the spec "you must not submit any code that is not your own work"?


The SwingWorker does more than you need for this assignment. Each business command should start a thread which communicates with the database or network. When the command needs to change the gui or is done it should inform its clients by using SwingUtilities.invokeLater. The client objects (eg. the model) should probably register as listeners using the Observer pattern. The code within the invokeLater's run method should fire an event to all registered listeners. I posted an example of this on another thread this morning.
Michal Charemza
Ranch Hand

Joined: Jul 13, 2004
Posts: 86
So don't worry about your code ending up similar to Sun's code - there are cases where this will happen even if you are unaware of it (especially for those people learning RMI for the first time, and using it in their assignments - their RMI implementation is going to be almost identical to the Sun tutorials ).

Others have done this in the past and passed, so this does not appear to be a problem.


Thanks Andrew, if I do go down this route I will not worry.


Each business command should start a thread which communicates with the database or network. When the command needs to change the gui or is done it should inform its clients by using SwingUtilities.invokeLater. The client objects (eg. the model) should probably register as listeners using the Observer pattern. The code within the invokeLater's run method should fire an event to all registered listeners. I posted an example of this on another thread this morning.


Peter, I do see what you mean. Perhaps this is a better way of doing it. I had planned to put all my listeners as inner classes (just to check... this is the observer pattern right?). So I will have a "listener" inner class for each of my buttons , and also "listener" class for events that are fired from threads that communicate with the server, that will update the GUI. This way, all responses to all events are together in the source file.

Am I interpreting your answer correctly?

Michal

p.s. I am about to get on a plane to see my Grandmother, so I won't be able to respond until Tuesday.
peter wooster
Ranch Hand

Joined: Jun 13, 2004
Posts: 1033
Originally posted by Michal Charemza:

Peter, I do see what you mean. Perhaps this is a better way of doing it. I had planned to put all my listeners as inner classes (just to check... this is the observer pattern right?). So I will have a "listener" inner class for each of my buttons , and also "listener" class for events that are fired from threads that communicate with the server, that will update the GUI. This way, all responses to all events are together in the source file.

Am I interpreting your answer correctly?

Michal


Yes, listeners are the observer portion of the Observer pattern. The observable, or publisher has methods to add and remove listeners and methods to fire events to all registered listeners. If you are using threads other than the Event Dispatch Thread, you will need to use SwingUtilities.invokeLater to ensure that the events fired back to the listeners are queued on the Event Queue.

My main point was that this is sufficiently different from the SwingWorker to not cause any worry about using others code. SwingWorker is much more closely coupled with its client and only supports a single client. The code I suggest is loosely coupled to its client by using the Observer pattern and supports multiple clients. In my project both the RoomModel and the ClientGUI register as observers of the RoomController. The model is interested in new data and the main gui is interested in changes in status.

/peter
Michal Charemza
Ranch Hand

Joined: Jul 13, 2004
Posts: 86
Originally posted by peter wooster:


My main point was that this is sufficiently different from the SwingWorker to not cause any worry about using others code. SwingWorker is much more closely coupled with its client and only supports a single client. The code I suggest is loosely coupled to its client by using the Observer pattern and supports multiple clients. In my project both the RoomModel and the ClientGUI register as observers of the RoomController. The model is interested in new data and the main gui is interested in changes in status.

/peter


Ok I thought I understood more on this topic, but I don't think I do.

In order for your ClientGUI (is this the "view" in MVC?) to register as observers of the RoomController, does this mean that the RoomController has to have a reference to the ClientGUI? In my book (Habibi, Mehran... is this "Max"?) it seems to be the other way around? Are both implementations of the MVC pattern?

Also, what do you mean by

"...the RoomModel and the ClientGUI register as observers of the RoomController. The model is interested in new data and the main gui is interested in changes in status."?

I don't know how this would actually translate into the structure of the code. What do the ClientGUI and RoomModel listen for?

Michal
 
It is sorta covered in the JavaRanch Style Guide.
 
subject: B&S: Multi threading, Swing, SwingWorker