CS11 Advanced Java Winter 2011-2012 Lecture 7Today’s Topics n Long-running tasks in Swing apps n A brief overview of Swing dialog windows n Logging n Conditional compilationBoggle Server n Last week: add the Boggle server! q RMI calls from clients to server to start/end games n Click the “Start Game” button: q Client calls the server’s startGame() method… q Client freezes for at least 15 seconds! q No UI updates at all! n Problem: q RMI call happens on Swing event-dispatch thread! q No Swing events can be processed while RMI call is waiting to returnSwing and Long-Running Tasks n Important rule for Swing UI programming: q Don’t perform long-running tasks using the Swing event-dispatcher thread! q Blocks the processing of other Swing events, and all UI updates, etc. n If a Swing app must do long-running tasks: q Run the task on a separate worker thread q Swing UI code hands the task to the worker thread, then monitors the worker’s progressSwingWorker n Swing includes a class to handle long-running tasks q javax.swing.SwingWorker q Creates and manages a worker thread to execute long-running tasks in a Swing-friendly way n How to use: q Create a subclass of SwingWorker for your task q Implement doInBackground() method to perform task n This method is called from the worker thread automatically q Override done() method to be notified when task is done n This method is called on the event-dispatcher thread n Can update user-interface from within this method!Subclassing SwingWorker n SwingWorker uses Java generics q SwingWorker<T, V> q T is the type of the final result produced by task n e.g. for call to Boggle server, T = BoggleBoard q V is the type of any intermediate results produced n Used for tasks that can produce intermediate results n If you don’t need it, just specify Object n Boggle client example: class StartGameWorker extends SwingWorker<BoggleBoard, Object> n Task returns a Boggle board n We don’t care about intermediate results, so specify ObjectImplementing doInBackground() n Signature of doInBackground(): q protected T doInBackground() n In your implementation: q Specify value of T q Can make the method public as well, but not critical q If implementation can throw, let the exceptions propagate! n Example: @Override public BoggleBoard doInBackground() throws PlayerException, RemoteException { return server.startGame(playerName); }Task Completion n The done() method is executed on Swing event-dispatch thread when task is finished q protected void done() q Default implementation does nothing q Override done() to perform your own tasks, e.g. updating your Swing UI q For Boggle client: n Display Boggle board returned from server, start timer, etc. n Get worker’s results by calling get() method q Returns same type as doInBackground() q If doInBackground() threw, calling get() will cause an ExecutionException to be thrownUsing the SwingWorker Class n Simple procedure to use Swing workers: q Create an instance of the SwingWorker subclass q Call the execute() method on it n Method starts worker thread, then returns immediately n Your code can call execute() from any thread, including event-dispatch thread n SwingWorker object can only be used once q Cannot reuse a SwingWorker object! q Just create a new one, then call execute() on itSwingWorker Notes n Good idea to implement SwingWorker as a private inner class q Can access application’s state directly q Can manipulate UI objects directly n The get() method blocks if the task isn’t finished! q A good reason to call get() from inside done() q Can use isDone() method to check if task is finished n SwingWorker has other features too q Can cancel in-progress tasks q Can produce intermediate results and monitor progressDialog Boxes n Dialog boxes (aka “dialogs”) are pop-up windows q Report errors or other important messages to the user q Request specific input values from the user q Display final results or details of some task to the user n Two kinds of dialogs: q Modal: n No other window in the application can receive user input until the dialog window is closed n System-modal dialogs block all applications until closed q Modeless: n Other windows in the application can still receive user input while dialog window is visible n In Swing, dialog classes derive from JDialogJOptionPane Dialogs n Swing provides JOptionPane for most common dialog needs q Simple informational or error dialogs q Getting a single field of input from user q Requesting yes/no-type confirmation from user n JOptionPane doesn’t derive from JDialog! q Can’t create a JOptionPane and show it directly q Have to embed a JOptionPane in a dialog object n JOptionPane creates modal dialogsJOptionPane Dialogs (2) n JOptionPane provides static methods to handle most common dialog tasks n Example: JOptionPane.showMessageDialog(frame, "Error while contacting server:\n" + e.getCause(), "Server Error", JOptionPane.ERROR_MESSAGE); q Shows an error message to the user q Specify parent frame so that dialog is centered in the frame q Result:JOptionPane Dialogs (3) n Static methods: q showMessageDialog(...) n Tell the user about something that has happened q showConfirmDialog(...) n Asks a question requiring confirmation, e.g. yes/no, ok/cancel, etc. q showInputDialog(...) n Prompt the user for a single field of input q showOptionDialog(...) n The general-purpose version that exposes all of the above capabilitiesHiding and Disposing Dialogs n Dialogs are shown by calling: dialog.setVisible(true); q If dialog is modal, this call doesn’t return until dialog is closed n Can hide a dialog (or any window) by calling: dialog.setVisible(false); q The window’s UI resources are still held! n To release a window’s UI resources: dialog.dispose(); q Will also hide the dialog if it is