This week's book giveaways are in the Java EE and JavaScript forums.
We're giving away four copies each of The Java EE 7 Tutorial Volume 1 or Volume 2(winners choice) and jQuery UI in Action and have the authors on-line!
See this thread and this one for details.
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes Freezing the UI thread Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of The Java EE 7 Tutorial Volume 1 or Volume 2 this week in the Java EE forum
or jQuery UI in Action in the JavaScript forum!
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "Freezing the UI thread" Watch "Freezing the UI thread" New topic
Author

Freezing the UI thread

Marcos Motta
Ranch Hand

Joined: Apr 28, 2002
Posts: 56
Has anyone cared about the client's GUI thread being freezed as a consequence of slow server requests? How did you addressed this issue?
I was thinking of creating a separate thread for each request and update the UI back with the results using something like SwingUtilities.invokeLater(), but I am affraid that this would make the source code too complex for the "junior" programer.
Your comments are very welcome
Damian Ryan
Ranch Hand

Joined: May 09, 2003
Posts: 117
I used a reusable thread within my client model to handle database requests. When the user clicks a button (or menu item) in the gui, its ActionListener's actionPerformed method is invoked in the AWT thread. This ActionListener calls into code within the client model (still within the AWT thread) and here the reusable thread has a "task" queued into it to perform the activity corresponding to the user's mouse click/keystroke (for example, "list all records"). The AWT thread returns immediately from the method invocation inside the client model and is again free to do its own thing, while the database access occurs in the reusable thread.
I used a reusable thread to save the overhead of spawning a new thread to deal with every user action.
Of course, this is just one way to address the issue you mentioned. I am sure there are others, perhaps simpler...


Always proofread carefully to see if you any words out.
Kristian Nydahl
Greenhorn

Joined: May 20, 2003
Posts: 1
Marcos,
I recommend you NOT to make a multithreaded client. You will not get any extra points because you have made a complex (and in you eyes better) solution. Keep it simple and accept that the gui freezes until your request returns.
I did exactly as you described and I lost 13 points on the General Considerations topic. I had full score on the server so I guess my client code wasn�t clear and readable enough.
You do not gain anything but work and complexity and your code will be less clear, readable and harder for juniors to understand.
Unfortunately simple solutions pays off.
That is my opinion,
Kristian Nydahl
Michael Morris
Ranch Hand

Joined: Jan 30, 2002
Posts: 3451
I was thinking of creating a separate thread for each request and update the UI back with the results using something like SwingUtilities.invokeLater(), but I am affraid that this would make the source code too complex for the "junior" programer.
That's what I did but used Observer and Observable to notify the client when the thread completed. I wouldn't worry too much about the complexity level of your code within reason. Mine was probably more complex than most and I only lost a point on documentation. Having said that, don't make it so complex that it is difficult to maintain or follow, that is where you will lose a junior programmer.


Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius - and a lot of courage - to move in the opposite direction. - Ernst F. Schumacher
Jim Yingst
Wanderer
Sheriff

Joined: Jan 30, 2000
Posts: 18671
I'm inclined to say it's a fundamental of good GUI programming that you avoid tying up the event handling thread with any time-consuming operations - that you delegate these to other threads whenever they visibly affect performance. Maybe this is not considered a requirement for SCDJ though.
[ May 20, 2003: Message edited by: Jim Yingst ]

"I'm not back." - Bill Harding, Twister
Michael Morris
Ranch Hand

Joined: Jan 30, 2002
Posts: 3451
I'm inclined to say it's a fundamental of good GUI programming that you avoid tying up the event handling thread with any time-consuming operations - that you delegate these to other threads whenever they visibly affect performance. Maybe this is not considered a requirement for SCDJ though.
I totally agree with that and would add that you could lose points on the GUI if you don't process remote requests asychronously. Think about how frustrating it is to a user when the GUI is locked up on an operation that takes more than a couple of seconds.
Damian Ryan
Ranch Hand

Joined: May 09, 2003
Posts: 117
I'd just echo what Michael and Jim have said. This was my motivation for accessing the database outside of the AWT thread.
I do not think my approach was overly complicated, but I will have to wait and see if the examiner agrees
[ May 21, 2003: Message edited by: Damian Ryan ]
Marcos Motta
Ranch Hand

Joined: Apr 28, 2002
Posts: 56
Ok, I am convinced. I will try to execute server operations asynchronously.
Now I have to figure out some way to do this in a way that the junior will
not be lost.
For the FBN there are only 4 essential operations that would be executed asynchronously:
-Connect
-Search for flights
-Book a flight
-Disconnect
I think that the steps required to implement the async execution are these:
1) Issue the request on a separate worker thread
2) Disable the appropriate UI to prevent multiple simultaneous requests
3) The worker thread finishes the job
4) Update the UI back with the results (UI thread)
5) Re-enable the UI thread (UI thread)

I plan to use this as a base for all sync operations:


and constructions like the folowing in my actionPerformed() handlers:


I am adminting the overhead of spawning a new thread on every request to keep things clear.
What are your comments on this strategy?
Do you think that use of anonymous inner classes derived from AsynchronousTask leads to confuse code?
Thanks for your opinions.
[ May 21, 2003: Message edited by: Marcos Motta ]
[ May 21, 2003: Message edited by: Marcos Motta ]
[ May 21, 2003: Message edited by: Marcos Motta ]
 
Consider Paul's rocket mass heater.
 
subject: Freezing the UI thread