This excerpt is from Learning ActionScript 3.0. Learning ActionScript 3.0 gives you a solid foundation in the Flash language and demonstrates how you can use it for practical, everyday projects. The book does more than give you a handful of sample scripts, defining how ActionScript and Flash work. It gives you a clear look into essential topics such as logic, event handling, displaying content, migrating legacy projects to ActionScript 3.0, classes, and much more. Written for those new to the language, this book doesn't rely exclusively on prior knowledge of object-oriented programming (OOP). Instead, it helps you expand your skillset by first focusing on clear, concise examples in the timeline, evolving into OOP examples over time-allowing you to choose the programming approach with which you are most comfortable.
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:
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:
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).
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.
|
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.
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.
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.
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 . 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 fOutput 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 this figure.
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.
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.
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:
This excerpt is from Learning ActionScript 3.0. Learning ActionScript 3.0 gives you a solid foundation in the Flash language and demonstrates how you can use it for practical, everyday projects. The book does more than give you a handful of sample scripts, defining how ActionScript and Flash work. It gives you a clear look into essential topics such as logic, event handling, displaying content, migrating legacy projects to ActionScript 3.0, classes, and much more. Written for those new to the language, this book doesn't rely exclusively on prior knowledge of object-oriented programming (OOP). Instead, it helps you expand your skillset by first focusing on clear, concise examples in the timeline, evolving into OOP examples over time-allowing you to choose the programming approach with which you are most comfortable.
Copyright © 2009 O'Reilly Media, Inc.