Hi,
I haven't done any Swing programming for 3 years but I am looking at it again now for the exam. When I last looked, swing components were not
thread safe and could only be updated within the event-dispatch thread. If you didn't update them in the event-dispatch thread then you ran the risk of them not working correctly. Normally (for quick tasks) this is not a problem since you would just process events in the same thread.
However, in this case we have an application that is performing IO (either locally and remotely) and this has the potential to take a longer time. When a long task is running, the event-dispatch thread would queue up other events and would prevent events such as repainting the display occuring until the long task is finished (which may be bad for the user if the call takes some time).
My usual approach to overcome this is to perform these potentially long tasks actions in a separate thread on the client. During this time I lock the user interface (by activating the glass pane, showing an hour glass etc.). When the task finishes, I would then call back to the user-interface with the results (using SwingUtilities.invokeLater) and then "re-activate" the user interface (i.e. hide the glass pane, show the normal cursor etc.). I would try and design a framework that did things consistently (i.e. a task framework).
My questions are
- Are Swing components still not thread safe?
- Is this overkill for the exam? I would have thought that for just local IO it might be but you might potentially have lengthy delays using a networked database.
- I'm not sure if this would have an impact on the MVC design (not my strongest area). I think I would have the task frame work running in the controller.
Thanks,
Paul Kelcey