Multithreaded Java GUI Programming
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
If there's one thing that differentiates the computer users of today from ten years ago, it's the need for motion! We've all become very impatient, and nowhere is this more apparent than in the area of GUI programming. The idea of waiting around for some clunky old GUI just seems to go against the grain. Indeed, some front-end technologies such as Ajax now seek to comprehensively solve the problem of screen updating by supporting asynchronous operation from the outset. The good news for Java developers is that making your Swing GUI code multithreaded isn't so very difficult.
I still remember the first multithreaded GUI I produced—it was around 1997 when I was working on a C++ product running on Windows NT. The application used an in-house developed GUI framework—this was high technology back in those days! Nowadays, of course you can take your pick when it comes to frameworks with many of them open source! However, in 1997, you often had to roll many of your own such components. In this case, the basic framework was single-threaded and the application supported some very long-running downloads from legacy telecom devices. I had to add code to the basic GUI framework to produce a multithreaded solution. As I remember, getting a C++ application to run with multiple threads of execution was a fairly straightforward tweaking exercise. With Java, it's even easier!
A Really Simple GUI
To get started, I want to create a simple Java GUI application, as illustrated in Figure 1.
)
Figure 1 A simple GUI.
In Figure 1, the GUI has two buttons and the usual window controls. If you click the Fill Screen button, the window starts to fill up with rectangular blocks, as illustrated in Figure 2. This filling process continues for a minute or two before returning control to the user.
)
Figure 2 A single-threaded, long-running operation.
While the filling operation in Figure 2 is occurring, you'll notice that you can't close the window in any of the usual ways—i.e., by clicking the Close button (marked as X in the right-hand corner) in the title bar, by clicking the GUI Exit button, or by left-clicking the top left-hand corner and selecting the Close menu option (or by pressing Alt+F4). Once you click the Fill Screen button, none of the usual program exit actions have any effect. This is because the GUI is single-threaded. You can of course resort to extreme measures to end the program by running the Windows Task Manager (assuming you're running Windows) and aborting the process. Obviously, the latter actions are only warranted in situations where programs or components fail, not when you just want to exit a simple Java program!
Going back to Figure 1, if you click the Exit button, you will be asked to confirm if you wish to exit, as illustrated in Figure 3.
)
Figure 3 A user-defined exit policy.
In Figure 3, if you click OK, the program exits, whereas if you click Cancel, the exit operation is aborted and the display returns to that illustrated in Figure 1.
However, if you've clicked the Fill Screen button in Figure 1, you can then press the Exit button as much as you like. It will have no effect until the fill screen operation is complete. Clearly, this isn't too satisfactory. Can the fill screen operation be moved into its own thread? Yes it can! Before we look at this, let's briefly review the code that produces the previous figures.