After having examined a few of the characteristics of threads, it's time to look at an example applet or two to drive home an understanding of how and why we might want to use them in the first place.Some of the most concise examples are actually given in Sun's Java Tutorial, and we're going to examine some of the more telling parts of one of them. Specifically, we'll supplement their illustration of the use of threads to background the loading of sounds.
We've already discussed the basics behind working with sounds within your applet (see past column on Sound in the Java API). As we related then, there are several methods defined both within the Applet class, as well as in a separate AudioClip class, for "loading" and playing files of a simple audio format. By loading, we mean the process by which the audio data are made directly available to the applet (i.e., in the same physical location, if not in the same storage medium) for immediate playback.
We also discussed the unfortunate side-effect of loading a large file, in that it would captivate whatever thread the loading was taking place in until the load was completed. Moreover, the load could not be counted on to occur when the getAudioClip() method was called for; instead, it could occur when the first actual "use" (e.g., playback) of the clip was called for.
As is wisely pointed out in Sun's tutorial, as a rule of thumb, any lengthy process like this one should be encapsulated in a thread. The point is illustrated in a SoundExample applet comprised of three closely integrated classes (the source for each is given here).
The main applet class, which ties the other two together, is primarily concerned with the specifics of the behavior of the applet's user interface (or at least, the majority of code in this class definition is for this purpose). As we described in our brief description of user interface objects, buttons are added, and the action() method is redefined, as are three of the four cardinal life-cycle event methods, namely:
- init()-- which places the buttons and kicks off the sound loading thread
- stop() -- which stops continuous processes (i.e., a sound loop) during a stop condition
- start()-- which starts the sound loop again, if it was subsequently stopped (e.g., should the user return to the page).
The second class is the SoundList. This is basically a data structure designed to hold AudioClips (in a hash table). It's extremely simple and works by extending the java.util.Hashtable library. It's also very closely integrated with the final class, which is the one we're interested in: the SoundLoader.
The SoundLoader is naturally just a small subclass of the Thread class. It's designed with a constructor that makes instatiating a SoundLoader object start the thread itself, which simply runs the getAudioClip routine and then stores the result in the SoundList.
We mentioned earlier that the getAudioClip method did not call for the sample to be transferred immediately as it was invoked. However, in this case, storing the audio data in the list is equivalent to playing it; it requires the sample to be on hand for processing. It forces the load, but, of course, this only concerns the SoundLoader thread, and these are only instantiated to deal with this problem in the first place.
Ironically, as you can see in the run() method of SoundLoader, the process of loading the small samples associated with this applet did not take long enough for this particular use of threads to be well illustrated; thus, a delay loop was included to simulate a long load time. Of course, since the delay was created with sleep(), and this is a thread, we're required to catch an exception. Exceptions--a metaphor for handling unexpected conditions within programs--are fairly interesting and versatile, and in the next few weeks we'll discuss them some further.
More evaluations and examples coming soon. Until next week.