Because clear communication is the cruxof good site design, mixed messages need to be kept out of all web applications. By using a Singleton pattern, you can help assure that you have a single source for messages to the user. This way, you’re less likely to send two contradictory messages. The following application uses a Single-ton for that purpose. It’s designed so that no matter where a message originates, it has only this one instance to deliver it.
To get started, open a new ActionScript file, and type in the script shown in Example 3-10.
Example 3-10. Alert.as package
{
public class Alert {
private var _msg:String;
private static var _instance:Alert;
public function Alert(pvt:PrivateClass) { }
public static function getInstance( ):Alert {
if(Alert._instance == null)
Save the file asAlert.as. As you can see, this Singleton design pattern doesn’t have to be saved as “Singleton,” and the only reason that name was used in the previous examples was to help you better see its structure, and where it belonged in the appli-cation. In fact, it’s almost identical to the otherSingleton.asfiles used as examples in this chapter, and even has the same methods as in Example 3-8. However, this exam-ple includes a property used as a variable in the font color of the text field used here.
Conceivably, your application may need different colored messages to differentiate categories of advisements your application might employ.
In ActionScript 3.0, you can create aTextField instance in one of two ways. First, you can create it dynamically in the script, as we will do in this example. Alterna-tively, you can create a MovieClip object on the stage, embed a TextField in the movie clip, and then reference the embeddedTextField. Unless you have a good rea-son for doing so, it’s more practical and uses less memory to just write the script for theTextField. (Further on in this chapter, a movie clip in the shape of a shopping cart with an embedded text field shows how to create and dynamically use a TextField object on the stage.)
Open a new ActionScript file and after entering the code in Example 3-11, name the fileAlertText.as and save it in the same folder asAlert.as.
{
Alert._instance=new Alert(new PrivateClass( ));
trace("Alert instantiated");
}
return Alert._instance;
}
//Alert Property
public var colorFont:uint;
//Alert Methods
public function getMsg( ):String {
return _msg;
}
public function setMsg(alert:String):void {
_msg = alert;
} } }
class PrivateClass {
public function PrivateClass( ) { trace("PrivateClass called");
} }
Example 3-10. Alert.as
When using something other thantrace( )statements in your applications, you need to import the necessary packages and classes for your application. Also, anything that you plan to place on the stage needs to be at least a Sprite or MovieClip. Because our application has no Timeline, we can use aSprite. Thus, theAlertTestextends theSprite class.
We need to mention a couple of concepts here for OOP beginners and those new to ActionScript 3.0. They include package parsimony and abstraction. As noted in Chapter 1, abstraction is a pillar of OOP, and you can see it in the Alert class where parameters and return values are abstract variables. The conceptpackage parsimony reminds us that when importing packages from the core set, you should import only what you need, and not the whole package. As you can see in the AlertTestclass, only the necessary classes were imported. While it can be tempting to use the wild-card asterisk (*) to bring in the whole package and save some typing time, this car-ries with it a lot of baggage. For example, instead of typing in the three lines,
import flash.text.TextField;
import flash.text.TextFormat;
import flash.text.TextFieldAutoSize;
we could have just typed in,
import flash.text.*;
Example 3-11. AlertText.as package
{
import flash.text.TextField;
import flash.text.TextFormat;
import flash.text.TextFieldAutoSize;
import flash.display.Sprite;
public class AlertTest extends Sprite {
However, had we done that, we would have added 15 classes of excess baggage. So while we would have saved a few strokes typing, we would have burdened the appli-cation with those unused classes.
You can see a somewhat odd example of abstraction at work in the single property colorFontincluded in theAlertSingleton class. ThecolorFontproperty is an abstrac-tion of any unsigned integer (uint). First, thecolorFontproperty is assigned a literal value, and second, that instance property is assigned to theformat.colorproperty.
Obviously, we could have assigned the color value directly to theformat.color prop-erty as a literal, but the purpose of putting thecolorFontproperty in the Singleton is to insure that only a single instance will be available for coloring the fonts. Thus, the abstraction of an unsigned integer in theAlertSingleton class insured that no color mix-up occurs.
To finish up, open a new Flash document, and typeAlertTestas the Document class name. Save the FLA file in the same folder as theAlertandAlertTestfiles. Figure 3-6 shows what you will see on both the stage and Output window.
In a typical application, you would use dynamic input for the message and color. For example, you might set up a user feedback system using different error or informa-tion messages, depending on what acinforma-tion the user takes. However, in the example you can see the fundamentals of setting up such a system using a Singleton and text field.