Learning ActionScript 3.0

Chapter 1. ACTIONSCRIPT OVERVIEW

While you likely know what ActionScript is and are eager to begin working with the new version, a brief overview of its development will give you some insight into its use—particularly related to Flash Player and how it handles different versions of ActionScript. This brief introductory chapter will give you a quick look at where ActionScript 3.0 fits into your workflow, and will cover:

• What Is ActionScript 3.0? It’s to be expected that a new version of ActionScript will bring with it new features. However, this version has been written anew from the ground up and is even handled separately from previous versions of ActionScript at runtime. This intentional splintering of Flash Player affords significant performance increases, but also brings with it limitations as to how multiple versions of ActionScript interact.

• The Flash Platform. At the time of this writing, ActionScript 3.0 is the internal programming language of Flex and AIR (the Adobe Integrated Runtime application). Differences in compiling and environment-specific attributes prevent every file written in ActionScript 3.0 from working in every aspect of the Flash Platform, but the fundamentals—indeed the bulk—of the language is the same throughout.

• Procedural Versus Object-Oriented Programming. A great deal of attention has been focused on the object-oriented programming (OOP) capabilities of ActionScript 3.0, and the power and robustness of the language really shine in this area. However, you’ll be happy to learn that a move to ActionScript 3.0 doesn’t mean that you must become an expert at OOP. It is still possible to use a structured collection of functions, which characterize procedural programming, to author ActionScript 3.0 projects. In addition, using Flash CS3, it is still possible to code in the timeline, rather than coding exclusively with external classes. If you prefer object-oriented programming, enhancements to ActionScript 3.0’s OOP infrastructure make it more robust and bring it more in line with the features of other important, OOP-based languages (such as Java) and make moving between such languages a bit easier.

• The Document Class. Object-oriented programming is not for everyone, but for those starting on this journey, Flash CS3 offers a simpler entrance to an OOP application by way of the Document class. An attribute of the Properties Inspector, you need only specify which external class is your starting point, and no timeline script is required.

• Legacy Code Compatibility. Because ActionScript 3.0 cannot co-mingle with previous versions of the language in the same file, developing projects that support older code is a challenge. We’ll briefly introduce the issues involved, and discuss them in greater depth in a later chapter.

What Is ActionScript 3.0?

Although the new version of Flash’s internal scripting language contains much that will be familiar to users of prior versions, it’s probably best to think of ActionScript 3.0 as entirely new, for a few simple reasons. First, a few things are quite different, such as the event model and the way assets are displayed. Second, subtle changes run throughout the language and require some attention until they become second nature. These are usually small concerns, such as a slight change in the name of a property.

Most importantly, however, ActionScript 3.0 has been rewritten from the ground up and uses a different code base than prior versions of the language. This optimization provides relatively dramatic performance increases, but it means that ActionScript 3.0 code cannot be mixed with prior versions of the language in the same file.

The newness of this version, however, shouldn’t intimidate you. It’s true that the learning curve for ActionScript 3.0 is steeper than for prior versions, but that is usually a function of its robustness more than one of difficulty. Typically, there is an adjustment period during which users must occasionally adapt to a slightly new way of doing things.

To help you get over any possible trepidation, here’s a look at some of the highlights of the new features of ActionScript 3.0. Keeping these benefits in mind may help make it easier to accept change, particularly when that change may initially seem tedious or overly complicated. Select new features include:

More detailed error reporting

ActionScript 3.0 requires strict data typing of variables, arguments, function returns, and so on. This data typing is discussed in Chapter 2, but boils down to telling the compiler what kind of data you expect to be working with at any specific time. Data type checking was introduced in ActionScript 2.0 but was previously optional. The heightened data typing enforcement improves error checking and provides more information while coding to allow you to correct the problem. Further, ActionScript 3.0 now enforces static data typing at runtime. This improves data type reliability at runtime, and also improves performance and reduces memory usage because the data types are stored in machine code rather than having to be dynamically addressed at runtime.

Syntax improvements

Syntax issues have been unified and cleaned up throughout the language. For example, property names have been clarified in some cases, and have been made consistent by removing the occasional leading underscores, as you’ll see in Chapter 3. Also, multiple, subtly different ways of approaching the same or similar tasks have been made consistent, such as when loading external assets (discussed in Chapter 13) or linking to a URL (as seen throughout the book).

New display architecture

The many previous methods to dynamically add something to the display environment are now consolidated. The new display list simplifies this process significantly and also makes it easier to change the visual stacking order, as well as parent, child, and sibling hierarchical relationships, of display objects. As a major change introduced by ActionScript 3.0, we discuss this at length in Chapter 4.

New event architecture

Still another example of improved consistency, all events are now fielded by event listeners—essentially listening for a specific event to occur, and then reacting accordingly. The new event model is also more powerful, allowing mouse and keyboard events to propagate through multiple objects in the display list. The event model is discussed in Chapter 3.

Improved XML handling

A formerly cumbersome process, working with complex XML documents is now a pleasure with ActionScript 3.0. Adopting the standard commonly referred to as E4X, ActionScript now treats XML objects in a much more intelligent and familiar manner. The new approach allows you to use the same dot syntax to string related objects together.

More text scripting options

New text-processing methods now allow for much finer control over text manipulation. You can now find the text of a particular line in a text field, the number of characters in that line, and the character at a specified point (such as under the mouse). You can also find the index in the text field of the first character in a paragraph, and even get the minimum-bounding rectangle surrounding any specific character. All these options not only make working with a text field easier, but also allow a tighter integration with the lines and characters in a field and their surrounding stage elements. Text is discussed in Chapter 10.

New regular expressions

Another boon to text handling is the new native support for regular expressions. Regular expressions are like text manipulation on steroids. Instead of manipulating only specific, known strings of characters, you can now manipulate text using wild cards, character types (numeric, alpha, punctuation, and so on), white space (spaces, tabs, returns), repeating characters, and more. A simple example of regular expression use can be found in Chapter 10.

More sound management options

ActionScript 3.0’s new sound capabilities are among the most eye-catching changes to the language. On a practical level, they improve access to both individual sounds and to all sounds playing. Sounds are now placed into separate channels, making it easier to work with multiple individual sounds, but also funnel all sounds through a sound mixer for collective control. You can also now get the amplitude and frequency spectrum data from sounds during playback. Sound is discussed in Chapter 11.

New access to raw data

For more advanced needs, you can now access raw binary data at runtime. Individual bytes of data can be read during download, during sound playback, or during bitmap data manipulation, to name a few examples. These bytes can be stored in a large list and still be accessed quickly and efficiently. We’ll show one example of this technique in Chapter 11 when discussing sound visualization.

New automatic scope management

In a programming language, the word scope is sometimes used to define the realm in which an object lives. A Flash asset, such as a movie clip, might be in one part of the Flash movie but not another. For example, a child movie clip might be nested inside one of two movie clips found in the main timeline. That nested movie clip exists within one clip but not the other. Its scope, therefore, is restricted to its parent. Programming structures have limited scope, as well, and the challenge is making sure you work within the correct scope when addressing those structures. ActionScript 3.0 greatly simplifies this by automatically tracking scope as you program.

Improved object-oriented programming

Object-oriented programming structures have also been improved in ActionScript 3.0 with the inclusion of sealed classes and new namespaces, among other things. We’ll discuss aspects of OOP in this chapter, as well as in Chapter 6, and provide class-based examples throughout the book. New in ActionScript 3.0, all classes are sealed by default, allowing only those properties and methods defined at author time to exist in the class at runtime. If you do find the need to change classes at runtime—by adding properties, for example—you can still do so by making the classes dynamic. Additionally, namespaces, including the ability to define custom namespaces, allow finer control over classes and XML manipulation.

The Flash Platform

It’s important to note that this book focuses primarily on developing ActionScript 3.0 applications using the Flash CS3 Professional integrated development environment (IDE). However, ActionScript 3.0 is the programming language for other Flash Platform applications, as well—notably Flex and AIR (the Adobe Integrated Runtime desktop delivery application).

Note

AIR projects can also include HTML, JavaScript, and PDF, but ActionScript 3.0 is a large part of its appeal and the language most relevant to this discussion.

This means that the scripting skills you develop in Flash CS3 will be largely applicable in other areas of the Flash Platform, extending your reach as a programmer. There are, however, some important differences to understand when examining the big picture of cross-application scripting. We’ll give you just a few brief examples here to consider.

To start with, Flash and Flex have different compilers so there is no guarantee that your project will compile correctly in both applications. You can use Flex Builder (the Flex compiler) to compile code-only ActionScript SWFs without the Flex framework, and load them into Flash CS3-generated projects. You can also load Flash CS3-compiled SWFs into a Flex project. However, as soon as you depart from core language needs, things start to get sticky.

For example, Flex does not have the resources of the Flash IDE to create visual assets (such as movie clips) and, by the same token, Flash does not support the Embed tag used by Flex to include such assets. This means that the same code cannot always be used seamlessly when such custom visuals are required. Similarly, the component architecture is different, including a different format and a component set that do not match.

This issue with visual assets has been a hotly debated issue for a while, and progress is being made to smooth the waters a bit. Adobe released a patch for Flex 2, and Flex 3 is in public testing at the time of this writing, improving the compatibility of components. However, it will probably be a while before moving code to and from these applications will be a comfortable process, if it ever happens. At a brisker pace, however, AIR development is becoming more of a crossover affair. Adobe is continuing to work on AIR authoring workflows that originate in Flash CS3.

The thing to keep in mind is that the ActionScript 3.0 language skills you develop will ease your move between applications in the Flash Platform, even if you must work with different authoring tools or compilers to end up with a finished product.

Procedural Versus Object-Oriented Programming

Much discussion has been made over the pros and cons of procedural versus object-oriented programming. To touch briefly on this, here is a little background concerning the evolution of ActionScript. ActionScript started as a sequential programming language, meaning that scripting was limited to a linear sequence of instructions telling Flash what to do in a step-by-step manner. This approach to scripting was not terribly flexible and did not promote reuse.

Note

The programming terms parent, child, sibling, ancestor, and similar words and phrases mean much the same as they do when used to describe families. In ActionScript, parent-child relationships can occur in multiple ways.

Movie clips for example, can be nested within each other. The upper- or outermost movie clip is sometimes referred to as the parent (there is even an ActionScript property called {parent}), while the clips nested inside are sometimes called children. Similarly, two movie clips at the same hierarchical level are siblings, and clips that are more than one parent up the chain of nested clips are called ancestors.

Both procedural and object-oriented programming also use these terms when a similar, family-like inheritance is implied. For example, when you create an instance of a class, as you will learn to do later, the instance is sometimes called a child object of that class. Conversely, an instance can usually invoke methods of its parent class. In general, if you liken these terms to their every day uses, referring to families, you will readily grasp their meanings.

As the language evolved, it became a procedural programming language. Like sequential programming, procedural programming relied on a step-by-step set of instructions but introduced a more structured, modular approach to scripting. Procedures, otherwise known as functions (or, sometimes, subroutines), could be executed again and again as needed from different parts of a project, without copying and pasting copies of the code into the ongoing sequence of instructions. This modularity promoted reuse, and made the code easier to edit and more efficient.

Scripters in search of an even greater degree of modularity and reuse gravitated toward object-oriented programming. OOP languages create programs that are a collection of objects. Objects are individual instances of classes—collections of code that are self-contained and do not materially alter or disrupt each other. Dividing code into small capsules, appropriately known as encapsulation, is one of the hallmarks of an OOP language. Another important feature of OOP is inheritance, or the ability to derive classes from parent classes, passing on specific characteristics from the parent.

A classic example of OOP structure, and specifically inheritance, defines a set of transportation vehicles. You might start with a generic Vehicle class that includes traits common to all vehicles, such as the basic physics of movement. You might then create three subclasses: GroundVehicle, WaterVehicle, and AirVehicle. These classes would alter or introduce traits specific to ground, water, and air travel, respectively, but not yet be complete enough to represent an actual vehicle. Further derived classes might be Car and Motorcycle (descending from GroundVehicle), Boat, and Submarine (descending from WaterVehicle), and Plane and Helicopter (descending from AirVehicle). Depending on the complexity of your system, you can carry on this process, creating individual models with individual settings for fuel consumption, friction, and so on.

As you can probably imagine, this approach to development adds additional power, flexibility, and prospects for reuse. These benefits, among others, sometimes position object-oriented programming as the best approach to a problem. However, there is a tendency among some programmers to believe that OOP is the best solution to all problems or, effectively, the only solution. This is a faulty assumption.

OOP is often best for very large projects, or for working with a team of programmers, but it can often be overkill for small projects. Additionally, for the uninitiated, it can significantly increase the learning curve, and distract from key topical concepts during your studies. In short, OOP is not always the best tool for the job. Procedural programming still has its place, and Flash CS3 allows you to explore and employ both programming paradigms.

This book attempts to introduce material using both procedural and OOP where appropriate. Using object-oriented practices is a fine goal, and one that we will encourage in this volume. However, we will try first to focus on the material central to each chapter, highlighting syntax and explaining how and why each topic should be addressed in code.

In general terms, we will focus on procedural programming prior to Chapter 6; this chapter serves as a transition chapter between procedural and OOP practices. After Chapter 6, the beginning of each chapter will focus on the topics being discussed, without intrusion by the surrounding OOP class structures. When appropriate, however, each chapter will end with an applied OOP example.

This is our preferred approach to presenting material for all possible users—in both procedural and OOP formats. It is our hope that, regardless of your skill and experience, you will home in on the topics at hand, and then work in the timeline, or in classes, based on your comfort level.

The Document Class

If you decide you would like to start thinking in OOP terms right away, we will show you how to easily take a step in that direction. Flash CS3 introduced a new feature that simplifies associating a main class, or application entry point with your FLA. It is called the document class and it does all the work of instantiating the class for you. This means you don’t need any code in the timeline at all, and can edit all examples in Flash or the external text editor or development environment of your choice.

Note

If you don’t plan to start using OOP until we roll it out in later chapters, feel free to skip this section as it will be repeated in Chapter 6. We will provide minimal explanation here just to get you going using the document class, and will explain this material in greater detail in later chapters throughout the book.

Let’s start with a simulated chapter example that you might use in the timeline. It does nothing more than use the trace() method to place a word into the Output panel—an authoring-only panel that accepts text output from your file.

trace("Flash");

To create a document class, you’re going to create a kind of wrapper that encloses the trace() method in the correct class syntax.

Create a new ActionScript file (rather than a new FLA document) and type the following document class shell:

1   package {
2
3      import flash.display.MovieClip;
4
5      public class Main extends MovieClip {
6
7          public function Main() {
8
9          }
10
11      }
12  }

The first line, along with the closing brace in line 12, defines the class’s package. A package is a mandatory structure that ensures your class is known to the compiler. Next, you must import any classes that you need to use in your package.

A document class essentially serves as a shortcut for creating an instance of a movie clip or sprite (a new Flash object that is nothing more than a one-frame movie clip) and adding it to the display list so it can be displayed by Flash Player. (This is true even when there is nothing to display, as in this case. We will cover manipulating the display list in Chapter 4.)

All document classes must be derived from either the MovieClip or Sprite class. (Other custom classes that are not document classes do not need to be extended from MovieClip or Sprite if that is not appropriate.) This example uses MovieClip so you must import the MovieClip class, as seen in line 3.

Line 5, along with its closing brace on line 11, is the class definition. Its name is arbitrary but, when naming it, you should follow a few basic rules and conventions. The name should be one word that does not already exist in ActionScript, it should start with an alpha character (rather than a number or other character), and it is typically capitalized. The class must be public, meaning that other classes can access the constructor, and it must extend MovieClip or Sprite, as described previously.

Line 7, along with its closing brace on line 9, is the class constructor. This is the main function that automatically runs when creating an instance of this class. It, too, must be public and must have the same name as the class. Other functions (if any) can, and must, have unique names. All that remains is to add the lone method required in this case. The constructor must trace “Flash” to the Output panel, so add the following to line 8:

7        public function Main() {
8            trace("Flash");
9        }

Once finished, you must save the file in the same directory as your FLA file for now. (Later on, you’ll learn how to place your class files in other locations.) You must give the file the same name as the class, but add an .as extension. Therefore, this file should be named Main.as. Now create a new FLA file, choosing ActionScript 3.0 as its programming language version, and save it in the same directory as your previously created class file. The name of the FLA is unimportant.

Finally, open the Properties Inspector and add the name of your document class, not the name of the document itself, in the Document Class field. In this case, type Main instead of Main.as, as seen in Figure 1-1.

Figure 1-1. Adding a document class to your FLA

Now preview your file. Doing so will create an instance of the Main class (which extends MovieClip and, therefore, behaves like a movie clip) and add it to the display list. The class will trace “Flash” to the output panel, and your test application will be complete.

Hereafter, you can try any of our timeline code in a document class of your own. Initially, you probably won’t know which classes to import or how to make any possible changes to variables or similar structures to conform to the class syntax. However, all the sample code will come with an accompanying class file for testing. You can use those files whenever you wish until you get used to the document class format.

Legacy Code Compatibility

I’d like to end this chapter with a small caveat. You cannot mix ActionScript 1.0 or 2.0 code with ActionScript 3.0 code in the same SWF. You are unlikely to do this if you’re learning from scratch, but you may run into this situation if you attempt to update legacy projects by adding ActionScript 3.0 code.

If you ever have the need to run a discrete mixture of ActionScript 3.0 and a prior version of the language, such as showing a legacy file within a new demo interface shell, you can do so by loading a SWF. An ActionScript 3.0 file can load a SWF created in ActionScript 1.0 or 2.0, but it cannot access the older SWF’s variables or functions. For all intents and purposes, the same is not true in reverse. An older SWF cannot load an ActionScript 3.0 SWF.

In Chapter 13, we will discuss how to communicate between these two discrete SWFs using a special process. For now, however, just remind yourself again that you cannot combine ActionScript 3.0 with older versions of the language in the same file.

What’s Next?

Now that you know a little more about ActionScript 3.0 and the Flash Platform, it’s time for a look at some of the fundamentals of the language. By reviewing version-independent concepts at the outset, we can focus on new syntax in subsequent chapters. If you have a lot of experience with ActionScript 1.0 or 2.0, you may wish to skim this material.

In the next chapter, we’ll discuss:

• Basic concepts to bring you up to speed quickly, including using the trace() method as a diagnostic tool to see immediate feedback from your scripts

• Using variables to store data, including arrays and custom objects that allow you to easily manage more than one value, and data typing those values to improve error reporting

• Logical structures such as conditionals for decision making and loops for simplifying repetitive tasks

• Functions that can isolate code into convenient blocks that will be executed only when instructed

• Ways to address Flash objects with ActionScript, including using absolute and relative paths, and the shortcut identifier this