Win a copy of Design for the Mind this week in the Design forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

B&S: Multi threading, Swing, SwingWorker

 
Michal Charemza
Ranch Hand
Posts: 86
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 476
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Andrew Monkhouse
author and jackaroo
Marshal Commander
Pie
Posts: 11865
194
C++ Firefox Browser IntelliJ IDE Java Mac Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
peter wooster
Ranch Hand
Posts: 1033
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 86
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 1033
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 86
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic