Win a copy of Programmer's Guide to Java SE 8 Oracle Certified Associate (OCA) this week in the OCAJP forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Freezing the UI thread

 
Marcos Motta
Ranch Hand
Posts: 56
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 117
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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...
 
Kristian Nydahl
Greenhorn
Posts: 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 3451
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Jim Yingst
Wanderer
Sheriff
Posts: 18671
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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 ]
 
Michael Morris
Ranch Hand
Posts: 3451
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 117
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 56
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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 ]
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic