Overview

If you’ve ever want to incorporate web services into your graphical applications/applets/widgets written in Java, then there are some threading issues that you have to be mindful of, and design around. This tutorial will guide you though some of the important threading issues you have to keep in mind when building such applications. The strategies outlined in this tutorial apply to accessing more than just web services from Swing apps; it also applies to loading information from databases, and performing any other kind of time consuming process that has to happen in the desktop app and interact with it, but can’t make the user interface unresponsive.

Background

For some more background information on Swing applications and threading, read this article – Lesson: Concurrency in Swing. The Swing framework is essentially single threaded, as are most GUI toolkits. The main thread which updates the UI is called the Event Dispatch Thread (EDT). All the graphical components are created by this thread, all the action, event, etc. listeners run in this thread. So if your code performs a long running/time consuming or blocking task in the EDT, then the Swing UI will become frozen until your code is done. In order to prevent this situation, there are other threads that your tasks can use:

You can leverage some worker threads that Swing itself creates so that background tasks can be performed outside of the EDT for long running/time consuming/blocking operations that your task must perform, or

You can use threads that you explicitly create and then coordinate the output from these threads with the EDT, or

You can take a blended approach and do both of the things suggested above.

In this tutorial, I will cover all three strategies for making your Swing apps multithreaded, with code examples, and things to keep in mind when designing such systems.

Perform a one-shot task, started from the user interface, that only needs to update the UI with the final result of the task. Use a Swing threadpool executor to perform this task (not the EDT).

Diagram:

Notes:

You have to create a subclass of SwingWorker and launch it by calling execute(); this will probably happen in an ActionListener in your Swing code. Calling execute() submits this SwingWorker task to the threadpool that Swing keeps for running background tasks. The execute() method returns immediately; so your calling thread (which may be the EDT itself) will continue.

Put the code for the background task in T doInBackground(). This is the code that performs the time consuming one-shot task. If exceptions are generated here, they can be caught by a call to T get(), so can the return value. Once this method completes (on the background thread), done() will be called on the EDT. The return value is of type “<T>” – this is whatever class you decide to make the doInBackground() method return. “<T>” is the result type returned by this SwingWorker’s doInBackground and get methods. You can either implement this time consuming task in this method, or you can call an external web service, or other gateway or proxy class to request something.

The done() method is called on the EDT when your doInBackground() method exits (by returning a value or throwing an exception). In the done() method, you can retrieve the thrown exception or return value by calling get(). In this method, you have to perform whatever GUI updates, or interactions that are necessary with the return value or exceptions generated by the call to get().

In this case the thread is started by calling execute() on the SwingWorker task itself. This submits the task to a threadpool of background threads that Swing manages, and the task will be executed in one of these threads.

Please make sure that the task is easily interruptible – there is no way to preemptively interrupt/stop a thread in Java, only cooperative cancellation is possible.

So, if you are performing any wait operations (waiting on a lock or monitor) make sure to catch the InterruptedException and cancel out of the task.

If you are performing blocking IO, make sure to catch IOException, to cancel out of it. The underlying stream that this task is blocking on has to be closed. Presumably, the object calling cancel(true) on your SwingWorker task will also have to call close() on the underlying Input/OutputStream in order for this to work. If you are unblocked due to to an IOException, you can always check for isCancelled() on the SwingWorker to see if it’s been cancelled.

Also, make sure to check isCancelled() on the SwingWorker thread to see if the task has been cancelled, to end your task.

If you don’t know what to do with the InterruptedException (if one is thrown), and if you catch it, make sure to call Thread.currentThread().interrupt() to maintain the interrupted flag, so that the executor running this thread will know what to do with the interruption. More on preserving thread interrupted state (if you don’t know what to do with the caught InterruptedException is explained here).

Perform a one-shot task, started from the user interface (or not), that only needs to update the UI with the final result of the task. Use your own executor to perform the task (not the EDT, or a Swing threadpool executor).

Diagram:

Notes:

The only differences between Strategy 1 and 2 are the following:

In Strategy 2, instead of performing the time consuming task in the doInBackground(), you simply delegate this responsibility to another task being executed in a different executor (which has it’s own thread(s)). The reason for doing this is that you may have some multithreaded components/libraries/objects that you’ve created that are not tied to Swing. You may have a proxy class that acts as a gateway to an external web service. Instead of having to link this code to Swing’s SwingWorker, you can use a generic Executor or Callable or Runnable to implement this. Then you have the task of tying this underlying threaded component to a SwingWorker, basically by creating an SwingWorker adapter for your underlying threaded component. All the processing happens in your underlying component, and the results are trasmitted to the SwingWorker task. So how do you pass a return value in case your underlying component implements Runnable? If the underlying component implements Callable, and you have a reference to a Future, it’s easy – you can just call get() and wait in the doInBackground method of your adapter. However, if you don’t have an reference to a Future, and you are dealing with Runnable implementation, then you will have pass the results back to doInBackground’s thread via a BlockingQueue<T>. So your SwingWorker adapter will have to get a reference to this BlockingQueue<T> when it’s created, and then in the doInBackground method, it will wait until it gets an object of type <T> from this queue. Your underlying threaded component will have to pass the results of its computation via this BlockingQueue<T> as well. This is a contract that must be honored by both your SwingWorker adapter class, and the underlying threaded component, in order for this strategy to work.

If your underlying component uses Callable, instead of Runnable, then there’s no need to use a BlockingQueue<T>. The doInBackground method of your SwingWorker adapter can simply call the get() method on the Future returned by the execution of the Callable. In this case, the blocking/waiting still happens in the doInBackground method, so that when everything is completed, done() is called on the EDT. In this scenario, Strategy 2 is very similar to Strategy 1, the only difference being that the doInBackground method doesn’t really implement anything, it just uses a Future to get a return value back from your underlying component (which is treaded).

The similarities between Strategy 1 and 2 are the following:

You don’t really use publish or process methods (which you will in Strategy 3).

The SwingWorker subclass is very similar, you have to declare a subclass in both cases like this: MySwingWorkerTask <T, Void> extends SwingWorker…

Perform a long running or recurring task, started from the user interface (or not), that needs to update the UI with intermediate/periodic results from the task. No final result has to be returned by the task (this is optional). Use your own executor to perform this long running/recurring task (not the EDT, or a Swing threadpool executor).

Diagram:

Notes:

The SwingWorker subclass is defined as SwingWorker<Void, V> : The reason the first parameter type is Void, is due to the fact that the final result returned by doInBackground is not important. However, unlike the previous strategies, the 2nd type parameters is <V> – this is the type of the intermediate values that are passed from the background thread to the EDT via publish -> process.

Once this SwingWorker task is started, it continually blocks on the BlockingQueue<V> object that the underlying threaded component uses to pass intermediate objects back to the SwingWorker adapter. The done() method isn’t used, and neither is get(); instead the publish() and process() methods are used in this strategy. As soon as an object is available on the BlockingQueue<V>, the SwingWorker task simply publishes that object. When objects are published, the EDT is notified of this, and it calls process() to get the objects that were published. Multiple calls to publish() are coalesed into one call to process() which is why the process method takes a List<V> chunks object as a parameter.

The EDT actually runs the process method, so this is where you want to update your GUI and return.

Enjoy!

Further reading in related categories

Graphics

I was trying to create dialogs and alert dialogs that look the same on all Android smartphones, after he realized the different types of smart phones do something different with the default themes and make buttons, dialogs, etc. look very different from one phone to the other. Everything looks very different in the simulator than it does on a Droid X or Droid 2 for example. Things look more similar on a Samsung Galaxy S, or HTC Incredible, but even there you can see some differences.

Some Android phone manufacturers replace the default themes, and styles, and drawable assets with what they think looks good and customized. Unfortunately, the side effect of this customization is that what works great in the emulator, and most phones simply does not work these devices. Eg, Motorola Droid 2 and X have a customized theme that uses really dark backgrounds, and red foreground colors. This can wreck many applications that are designed for a light background with dark text color.

In this tutorial, I will show you how to quickly manage screens using the RIM UI API. The BlackBerry OS maintains a stack of screens, and your app can be pushed and popped from this stack. These are normal screen display operations. You can even hide your screen from the display, and it will show the BlackBerry home screen. You can close the screen as well.

More details on the Task API introduced in the first Task API tutorial. SampleApp from the first tutorial is dissected under a microscope along with the API itself. Also contains information on which external libraries are optional and which are required.

Introducing the Task API. Easy to use background task API for Swing. Android and JavaME implementation coming soon. Easily create tasks and monitor their progress and cancel them at any time. Easily manage multiple tasks. Create network aware tasks and recurring tasks, and much much more! The API is open source (Apache 2.0 license). Enjoy!!!

This tutorial will show you how to use SwingX's JXBusyLabel component to display an indeterminate progress indicator. It will also show you advanced configuration options that allow you to create different and interesting indeterminate progress indicators using the BusyPainter.

This tutorial will walk you through the steps required to use JXTaskPane and JXTaskPaneContainer in SwingX. You will learn how to change the default color schemes of these components, and add components and actions to task panes.

I needed to perform animations in the app that I'm building (http://screamingtoaster.com). I needed to build animations that show a transition from one screen to another. This is slightly different than creating custom, or modified components which perform a function and have a set of graphical effects. I needed animations that would transition my user interface from one "screen" to the next. The screens themselves could be panels or components (part of the whole app, or the entire app itself). While I'd been writing much of this code myself, to do these animations, it just got really tedious and frustrating to add this level of complexity to my code, when all I needed were some simple animations. I've been using the SwingX API and the TimingFramework API to perform the animations and leverage the components, however, this last piece was missing. And this last piece just got delivered by Chet Haase, as a part of the binary deliverables with his (and Romain Guy's) great book - Filthy Rich Clients.

I needed to perform animations in the app that I'm building (http://screamingtoaster.com). I needed to build animations that move various components around on the screen, and other animations that pop up components on top of existing components, etc. After creating a few of these effects, I realized that I was doing the same thing over and over again, which is why I decided to write this tutorial to encapsulate this pattern, in the hopes that I will help others doing the same thing.

Multithreading, Concurrency

This tutorial will show you how to instantiate or inflate a View from XML; this is useful for components that don't provide a Java API to tweak with certain style attributes. The Button class is used as an example; you can only get certain styles to show up via XML that aren't available via the Java API.

I've written 3 tutorials to show you how to create a service enabled Android application that performs all of it's network I/O in a background thread (not the UI thread). These tutorials are split into three parts. This tutorial shows you how to use background threads to perform long running network IO operations, so that the main UI thread is not locked up.

More details on the Task API introduced in the first Task API tutorial. SampleApp from the first tutorial is dissected under a microscope along with the API itself. Also contains information on which external libraries are optional and which are required.

Introducing the Task API. Easy to use background task API for Swing. Android and JavaME implementation coming soon. Easily create tasks and monitor their progress and cancel them at any time. Easily manage multiple tasks. Create network aware tasks and recurring tasks, and much much more! The API is open source (Apache 2.0 license). Enjoy!!!

SOA

I’ve been building web, mobile, desktop apps that are powered by the ScreamingToaster ONE Platform for the last 3 years. I’ve had to integrate with a lot of services, like weather, credit card payment processing gateways, GeoIP lookups, CellID lookups, etc. One of the easiest integrations I’ve had to perform is with Twitter :) . Twitter has a simple to use API that can be accessed using Java or just about any other language. There are some really good Java wrappers for this API, and I’m going to highlight a really good one in this tutorial. I’m also going to show you how to integrate with Twitpic using Java.

I’ve build payments and licensing infrastructure for my ScreamingToaster ONE Platform, that allows mobile, web, and desktop software to share the same payments and licensing services. For payments, I integrated with FirstData Global Gateway, using the LinkPoint API. The LinkPoint API is good and FirstData provides lots of documentation that shows you how to get started. However, there is one huge flaw in their API and support docs – they don’t show you how to connect to the LinkPoint TEST gateway. All the code and examples are geared to connect to the PRODUCTION/LIVE gateway. If you’re like me, you want to test your stuff before hooking up to the LIVE gateway :) . So this tutorial is dedicated to simply connecting to their TEST gateway, so that you can test your code before going live.

Given an IP address, this tutorial will show you how to get geographic location information from it. You can then use this location information for many different things, like looking up weather there, or perhaps displaying a pushpin on google maps, etc. This is the second part of a 3 part series of tutorials on geocoding.

Given an IP address, this tutorial will show you how to get geographic location information from it. You can then use this location information for many different things, like looking up weather there, or perhaps displaying a pushpin on google maps, etc. This is the first part of a 3 part series of tutorials on geocoding.

With web services, SOAP and XML RPC and sessionless RESTful protocols becoming popular over the last few years, this tutorial will take you through the steps of crafting a very lightweight RPC mechanism that uses Java's object serialization and HTTP (URLConnection and Servlets).

"What is SOA?" This is a white paper on the definition of SOA (Service Oriented Architecture) and what ecosystem it fits in, and issues that are relevant to people at various stages of adopting this paradigm.

If you've ever wanted to access weather reports from your desktop applications, widgets, or web applications, I've got some source code that will make it easier than ever to access this weather data from a Java API.

This entry was posted
on Monday, January 8th, 2007 at 11:00 am and is filed under Graphics, Multithreading, Concurrency, SOA.
You can follow any responses to this entry through the RSS 2.0 feed.
Both comments and pings are currently closed.