Basic Class Packages in AS2

[ LiB ]

Ah, the last section of the last chapter. And I'm bringing up a topic that will easily fill another book twice the size of this one. I do want to orient you to AS2, but not as some afterthought or futile attempt to cram it all in. Rather, the best thing I can offer is an introduction to how AS2 is structured and how you can get started putting it to use. For me, the hardest aspect of learning is taking the first steps to apply all the tidbits I gather by reading or looking at others' solutions. This section attempts to put things in perspective so that you can get a good idea where things fit.

Anyway, AS2 is a formalized set of rules for ActionScript. The intention is for ActionScript to be more like other object-oriented languages such as Java and C#. It's not quite AS1 with more stuff (although, there are several added script elements). Instead, AS2 enforces syntax rules to even your old AS1. If you set your Publish settings to AS2, for example, you'll be able to use things such as strong data typing and the new Error object. However, with this setting, something that may have worked in AS1 will no longer work. For example, in MX you could use the following:

 var myName="Phillip"; trace( myname ); //and see "Phillip" 

In contrast, AS2 is case sensitive, so you will see undefined unless you use the following:

 trace(myName); 

Obviously, the idea of AS2 isn't just to make things difficult. Some would argue myName is different from myname , which when you use AS2 and publish for Flash Player 7, it is. It's hard to demonstrate the differences because it's more than just AS1 versus AS2. You've given Publish options for AS1 or AS2 as well as what version of Flash Player you will require. For example, you use AS2 even if you're delivering to Flash Player 6. You'll have to select this option if you want to use the V2 components . You'll only encounter the case-sensitive issue when using AS2 and delivering to Flash Player 7.

Subtle details of AS2 have already popped up a few places in this book. The following section describes the topic of class files. Class files are a modular way to keep generic functions external to your application. That is, you can make a library of useful classes, store them adjacent to your installed version of Flash, and use them in any project.

Structure

True to the modular nature of AS2, each class appears in its own class file. The filename is the class's name plus .as. (By convention, classes are capitalized.) You'll find all the installed classes that ship with Flash in the global class path that is, a folder in your Local Settings Configuration folder. On my machine it's in this path :

 C:\Documents and Settings\Phillip\Local Settings\Application Data\ Macromedia\Flash MX 2004\en\Configuration\Classes\ 

You'll find this "global class path" specified when you select Edit, Preferences, ActionScript tab. Figure 13.9 shows $(LocalData)/Classes , which is a dynamic reference to the long folder path above. (You should also see a period on the second line so that the folder where you save your FLA is also included in the class path.)

Figure 13.9. The default class path is set globally through Edit, Preferences.

You can import any of those class files into your application using import . For example, components that need the DepthManager class include this line of code:

 import mx.managers.DepthManager; 

This means that the file DepthManager.as is inside the folder managers inside the folder mx, which is inside the global class path. Notice dots are used rather than slashes . Also, all folders and filenames are case sensitive!

To make your own class, first create a file (for instance, MyClass.as). If you make a folder called mine inside the Classes folder, you need this code in your movie:

 import mine.MyClass; 

This is similar to the old include() directive that enables you to embed code from an external file. Using import gives you access to all the code inside the class file. Also, you can import all classes in the mine folder if you use the following:

 import mine.*; 

Incidentally, you can add additional class paths. The settings made in Edit, Preferences affect all applications you create. In addition, you can specify document-specific class paths through the Publish settings. Finally, you can also store AS files adjacent to your FLA and you don't even need to import them. Although this is convenient , you'll encounter a downside when you see how the first line of code in a class file refers to the class itselfand its path.

The structure of class files is detailed and unforgiving. It's necessary, however, so that that classes can import and share code from other classes. The Flash UI components rely on that structure as a way to eliminate repeated code. Be sure to read all the Help files in Flash; they cover the subject effectively.

Basic Skeleton

You're welcome to explore the contents of any of the classes that appear in your Local Settings folder. You can open them with any text editor, including Dreamweaver and Flash MX Professional 2004. Start by considering the following simple example of the contents of a class file named MyClass.as:

 class mine.MyClass { function repeatMe(param:String):String{ return ("you said "+param); } } 

Notice the name of the class ( MyClass ) appears after the path to that class (that is, inside the folder mine). Also notice I'm using strict data typing with colons that cast as strings both the parameter received and the value returned. Basically, repeatMe() becomes a method of every instance of this class. For example, the following code imports the class, makes an instance, and then triggers the repeatMe() method:

 import mx.mine.MyClass; var myInstance:MyClass=new MyClass(); var reply:String = myInstance.repeatMe("hi"); trace(reply); 

Of course, I expect your class methods to get a bit more involved.

You can go in several directions from this point:

• You can add more features to this class, such as additional methods and implied getter/ setter properties.

• You can separate private methods from public methods by using what's called an access modifier . This reduces the access given to developers, which is primarily to reduce the amount of effort to use the class.

• You can "extend" other classes. That is, your class can be a subclass of another. This means the subclass can do anything its parent class can (called the super class ). The subclass has extended capabilities: either additional methods or methods that override same-named methods in the super class (called specialization ). For example, you could make a clip that's a subclass to the Movie Clip class. Your clip will begin life with all the same methods and properties of movie clips, but you can add more or override methods as needed. This is equivalent to how you can extend the prototype property of an object.

Implied get / set Methods

By now you've seen how true properties available in V2 component instances make setting and getting properties easy and direct. In the past, you could access properties only via methods, which made code messy. The properties you define for your class instances can also use this same protocol. You still define methods (one for how to set a property, and one for how to get a property). However, implied get/set methods include an extra word (not surprisingly: get and set ). The code in Listing 13.3 shows you a getter/setter property called area .

Listing 13.3. Implied getter / setter Property

 1 class mine.MyClass 2 { 3 var width:Number=10; 4 var height:Number=10; 5 function get area():Number { 6 return width*height; 7 } 8 function set area(val:Number):Void { 9 width=Math.sqrt(val); 10 height=Math.sqrt(val); 11 } 12 } 

This example is pretty simple compared to the old addProperty() technique required in AS1.

Notice that I created a property called area , but that doesn't appear anywhere like the width and height properties. In fact, an implied getter/ setter property can't. It's really not so much a property as a function for which there is both a get and a set version. The get version (line 5) has the job of just returning a value in place of anyplace the developer uses myInstance.area . The set version (line 8) can perform any operation you want. In this case, I'm setting the width and height properties. Realize that for the simple properties height and width , I don't have any get/set functions defined. When the user sets one (for instance, myInstance.height=100) or gets one (perhaps, myVar=myInstance.height ), nothing happens internal to the class. Basically, for the properties you expect to affect other properties or display an immediate visual change, you'll want to set up get/set functions.

Here's how you could use the preceding class from inside Flash:

 import mx.mine.MyClass; var myInstance:MyClass=new MyClass(); trace(myInstance.area); myInstance.area=50; trace(myInstance.width); 

Note

getter/setter Properties Can't Match Internal Property Names

The weird part in the preceding listing is that you can't use the property name area inside the class. For this reason, you may need to maintain separate properties that use different names. If I want direct access to area inside the class, for example, I would make a different property (for instance, myArea ) and insert a line after line 10, such as myArea=val , so that it would mirror the area property.

Modularizing by Extending

You can do just a few other general things with classesbut they can get pretty advanced. Let me define some topics so that, when you do encounter them, you'll have a good basis of understanding.

Modularizing your classes can be as simple as making a separate class for every little thing and then importing several classes as needed for your app. In fact, class files can import other class files to leverage code written elsewhere. A much more elaborate version of the same idea is extending and implementing.

When one class extends another, it means it will have all built-in methods and properties of the class it's extending, as well as any you define in the class itself. To make one class extend another, you just add extends otherClass at the end of the first line, like this:

 class myClass extends otherClass; 

This means that any method in otherClass is available to all instances of myClass . This way you can write generic methods for the otherClass that are available to any class that extends it. Here's a simple example:

 class MyDate extends Date { function formattedDate ():String{ return this.getDate()+"/"+ Number(this.getMonth()+1)+"/"+ this.getFullYear(); } } 

With this code, I can say today=new MyDate() , and then later do everything I would normally do with the today instance as if it were an instance of the Date object. In addition, I could do something like trace(today.formattedDate() ).

Overriding is when one class can write its own version of a method found in its super class. If I want MyDate instances to respond to getDate() differently than normal, for example, I could just write a function like this:

 function getDate(){} 

If later I want to use the real getDate() method (that is, the one in the super class), all I need to do is use super.getDate() . You can think of the super keyword as a pointer to the super class.

Finally, class definitions can include properties or methods designated as public or private . The idea is that you may have the need for properties or methods that you want to shield from the developer using the class. Items designated as private are almost like local variables because there is no chance a subclass will override themeven if they use the same name.

Implementing an Interface

An interface is like a regular class except it has methods onlyno properties. And those methods are empty. An interface is basically a list of all the methods you expect to get overridden. One class can "implement" an interface. It looks the same as one class extending another:

 class MyClass implements MyInterface{} 

Unlike the hierarchy of subclass/super class, however, this arrangement just ensures MyClass uses the same method names found in MyInterface . (That is, its behavior is implemented the same.) This way, you might have several classes that each has its own implementation of the cleanUp() method. When you structure your classes, an interface defines how developers using the class will interact. It's like you're setting up the methods that will become available even before you define how they work.

[ LiB ]