HomeDigital EditionSys-Con RadioSearch Java Cd
Advanced Java AWT Book Reviews/Excerpts Client Server Corba Editorials Embedded Java Enterprise Java IDE's Industry Watch Integration Interviews Java Applet Java & Databases Java & Web Services Java Fundamentals Java Native Interface Java Servlets Java Beans J2ME Libraries .NET Object Orientation Observations/IMHO Product Reviews Scalability & Performance Security Server Side Source Code Straight Talking Swing Threads Using Java with others Wireless XML
 

During the development of our applets we discovered two problems. First, they all had different parameters for essentially the same action; second, the conversion of the parameters was done to varying levels of reliability. A reliable collection of methods to fetch parameters proved to be an invaluable way to ensure that all our applets used the same parameter names for the same actions and that the conversion of the parameters was done consistently and reliably.

Design Decisions
The primary objective of this class is to provide reliable reusable methods to fetch parameters. To accomplish this objective we required that the methods run and return meaningful data despite any errors in the parameters.

An assumption was made that this object would run only with applets, and that error messages, if generated, would not generally be seen. Therefore, error messages were deemed of little or no value. If a parameter isn't provided or is invalid, that parameter's method will return a default value. In addition, where it made sense, we decided that all parameter methods should return the type of the parameter, that is, a color parameter will return a color. In some cases conventions were established to reflect ease of use in the invoking code.

In the initial design we examined building a message object and associate methods with such attributes such as color, font style and direction. This proved limiting, as only a relatively small subset of our applets actually had messages associated with them. This approach could have also yielded a larger number of classes to download with a concomitant degradation in load and runtime.

The decision not to build a message object had an unforeseen ramification. If the message was not an object, then the font definition for the message would have to be done by the applet not in this object. While initially irritating, we came to view this as a feature. We discovered that while we frequently changed the font size and style, we almost never changed the typeface. We actually decided to leave it out of the final object as it didn't seem necessary!

The color determination function proved so ubiquitous in both applets and applications that we decided to break it out as a separate object. The fundamental function of this object was to receive either a hexadecimal color code or a string for a Java-supported color and return the color equivalent of that color string.

In the initial version of this class we ran most of the type conversions "commando," without the try and catch. The assumption was that the user was a technical user and would see the error and correct it. This proved to be a poor coding technique and resulted in unpredictable behavior that was difficult to debug.

In many of the applets there was a tendency to get all the parameters in the INIT() method and store them in variables. This caused problems for two reasons. First, the INIT() method is called only once after the initial applet load, while the START() method is called on every refresh, so a change in a parameter can be updated with a refresh. This is a very useful feature when fine-tuning a Web page. Second, the parameter is stored already. There is no reason to have a second variable for the same data. When you need it, use its associated "get" method. The advantage of this approach is that the values can change "dynamically" and are only fetched if and when they are required. This approach lowers the initialization time by distributing the parameter load time across all methods.

Determining Color
On the Web, color is everywhere. Many of our applications need and use color information as well. At minimum, an applet will need a foreground and background color; perhaps frames, panels or canvases will need additional color data as well.

A single method class to provide color determination seemed the optimal solution. The data can have only three formats and there was no easy way to separate them without analyzing the string data first. We also wanted to ensure maximum flexibility for the Web page developers by giving them as many choices as possible. This yielded a compact and efficient object that met all the criteria outlined above.

Because of the diversity of applications in which this class could be used, we elected to derive it from object rather than java.awt.Color, which seemed the most obvious point for it to extend from.

The function of this object is to translate a string that represents a color into that color. It fundamentally creates an expanded decode method that is available in java.awt.Color (Java version 1.1.x), by providing the ability to pass "#" initialized strings (as in HTML) or actual color names. Decode is not available in Java version 1.0.2, and this object must provide backwards compatibility for the most popular Web browsers. This class must implement its own decode-like logic. The original intent of the class was to work with applets. The decode method in version 1.1 supported decimal and octal options, but they won't be supported in this class.

This object contains one function, DetermineColor(String). The string may be one of three formats: a Java-supported color name, a six-digit hexadecimal number or a six-digit hexadecimal number preceded by a "#". The Java-supported color names are black, blue, cyan, dgray (for dark gray), gray, green, lgray (light gray), magenta, orange, pink, red, yellow and white. The reason behind the support of the "#" preceding the hexadecimal digits is that this is a supported format in HTML, and it would facilitate copying the colors into the parameter fields of an applet.

If the string is not a Java-supported color name, then it is tested to determine if it is a valid hexadecimal number. If so, it is converted into a color and returned. If it is not a valid number, the color is set to black. If the number is not the "proper" length, the color is set to white.

The Parameters
When we started this project we thought that the message would be the most common parameter. A survey of our applets showed that the colors and the dimension parameters were actually the most common. Following those were speed and direction.

The color parameters use the Determine Color class to return the color passed in the parameters. The parameters are "color_t" and "color_b", and the related methods are getForegroundColor and getBackgroundColor. If the value is missing, the default foreground color is white and the default background color is black. For either parameter, if the parameter is not acceptable (as outlined above in Determining Color), the returned color will depend on the error in the parameter.

The dimension parameters are used most frequently in the applet resize method. The parameters are height and width. The related methods are getHeight(Applet) and getWidth(Applet). Each method returns an integer. If the value is missing, the default width becomes 100 and the default height is 20. However, if it's invalid, the default width becomes 150 and the default height becomes 25.

The "speed" parameter is most frequently used in the Thread.sleep(long), which is the number of milliseconds to pause before continuing. Thus this parameter may also be used as a pause delay setting for a continuous operation. The default speed is 100 if the value is missing and 150 if it is invalid.

The direction parameters are probably the most unusual of this collection. Instead of returning a direction, it returns a signed integer. There are only three values it can have, +1, 0 or -1. These values were chosen to assist the computations for animation. We encountered scenarios in which we supported both horizontal and vertical motion; the parameters allowed us to define the type of motion for a particular implementation. Graphics areas start with the top left being 0,0. While the x-axis follows the algebraic notation, the y-axis is the opposite. It is best to think of this as an absolute value rather than signed. Horizontal scrolling is accomplished by incrementing to go to the right and decrementing to go left. Also, vertical motion is achieved by incrementing to go down and decrementing to go up.

The "message" parameter uses the getMessage(Applet) method to obtain a String message. There is no editing of the string. The default is "17 Web Place".

To date, only two font attributes were found to be of any interest; their parameters are "font_size" and "font_format". These parameters will be fetched using getFontSize(Applet) and getFontFormat(Applet) methods. Both methods return an integer value either the font point size or the integer equivalent to format (bold, regular, italic). The default font size is 12 if the value is missing and 10 if it is invalid. The default font format is "PLAIN".

Conclusion
This class provides a convenient, standard and reliable collection of methods to fetch parameters and use them in a wide collection of applets. The advantages of this encapsulation over a simple getParameter() method invocation are:

  • All or most parameter names are consistent across all of the corporate applets.
  • Standardized methods ensure reliable conversion, standard defaults and return values.
  • The added flexibility leads to a more robust use of parameters than is common in most applets.
About the Author
Mark A. Northrop has 18 years of experience on MVS, TPF, VM, RSX-11M-Plus, Windows 95, Windows NT, Unix and VMS operating systems, supporting systems and application software. He is a cofounder of 17 Web Place and is currently a technical engineer at Trans-World Airlines. Mark can be reached for questions or comments at [email protected]
 

All Rights Reserved
Copyright ©  2004 SYS-CON Media, Inc.
  E-mail: [email protected]

Java and Java-based marks are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries. SYS-CON Publications, Inc. is independent of Sun Microsystems, Inc.