Here are the first 9 paragraphs of Chapter 22 of Essential ActionScript 3.0.
22. Interactivity
In this chapter we’ll see how to add interactivity to an application by responding to Flash Player’s input events. Specifically, we’ll explore five different categories of input events:
* Mouse events
* Focus events
* Keyboard events
* Text events
* Flash Player-level events
For each of the preceding event categories, we’ll consider the specific events offered by Flash Player’s API and the code required to handle those events.
The descriptions of the events covered in this chapter apply specifically to Flash Player (both the browser add-on and standalone versions), but are also generally applicable to any Flash runtime that supports mouse and keyboard input (such as Apollo). When working with other Flash runtimes, be sure to consult the appropriate documentation for information on input events. For official reference material covering Flash Player’s input events, see Adobe’s ActionScript Language Reference under the “Constants” heading of the Event class and its subclasses. See also the “Events” heading under the TextField, DisplayObject, InteractiveObject, and Stage classes.
Before we start our examination of specific input events, let’s take a quick look at some general rules that govern all input events.
InteractiveObject Instances Only
Input-event notifications are sent to instances of classes that inherit from InteractiveObject only (i.e., Sprite, TextField, Stage, Loader, MovieClip, SimpleButton and subclasses of those classes.) Other types of objects are not notified of input events, even if those objects are on the display list. For example, instances of the Shape class can be placed on the display list, but the Shape class does not inherit from InteractiveObject, so Shape instances do not receive input-event notifications. If a Shape object visually overlaps a TextField object and the user clicks the Shape object, then the TextField object—not the Shape object—will be the target of the resulting mouse-click event. To handle interaction with a Shape or Bitmap object, place that object in a container (Sprite or MovieClip) and register with that container for input events.
Display List Objects Only
Objects that are not on the display list when Flash Player dispatches a given input event cannot receive notification of that event.
Default Behavior
Some input events trigger a native response by Flash Player, known as a default behavior. For example, moving the mouse pointer over a SimpleButton instance causes that instance to display its “over”-state graphic. In some cases, Flash Player’s default behavior can be prevented using the Event class’s instance method preventDefault(). For details see “Preventing Default Event Behavior” in Chapter 12.
Now on to the events!
Here are the first 6 paragraphs of Chapter 21 of Essential ActionScript 3.0
21. Events and Display Hierarchies
In Chapter 12, Events and Event Handling, we studied ActionScript’s built-in event architecture in general terms. In this chapter, we’ll take a closer look at how that event architecture specifically caters to objects in display hierarchies.
ActionScript’s system of dispatching events through an object hierarchy, as described in this chapter, is based on the W3C Document Object Model (DOM) Level 3 Events Specification, available at http://www.w3.org/TR/DOM-Level-3-Events.
Hierarchical Event Dispatch
As we saw in Chapter 12, when ActionScript dispatches an event targeted at an object that is not part of a display hierarchy, that target is the sole object notified of the event. For example, when a Sound object’s sound finishes playing, ActionScript dispatches an Event.COMPLETE event targeted at the associated SoundChannel object. The SoundChannel object is not part of a display hierarchy, so it is the sole object notified that the event occurred.
By contrast, when ActionScript dispatches an event targeted at an object that is part of a display hierarchy, that target and all of its display hierarchy ancestors are notified that the event occurred. For example, if a Sprite object contains a TextField object, and the user clicks the TextField object, both the TextField object (the event target) and the Sprite object (the event target’s ancestor) are notified that the mouse click occurred.
ActionScript’s hierarchical event dispatch system gives every display object container the ability to register event listeners that handle events targeted at its descendant display objects. For example, a Sprite representing a dialog box might register a listener that handles mouse click events targeted at a nested “OK button” control. Or a Sprite representing a login form might register a listener that handles focus events targeted at nested input fields. This centralized architecture helps reduce code repetition, particularly for code that responds to user input events. Later, under “Using the Event Flow to Centralize Code,” we’ll study a code example that demonstrates the benefits of centralized event handling. But first, let’s cover the basics of hierarchical event dispatch and registration.
In this chapter, the terms “ancestor” and “descendant” refer primarily to objects in a display hierarchy, not to superclasses and subclasses in an inheritance hierarchy. To avoid confusion, this chapter sometimes uses the informal terms “display ancestor” and “display descendant” when referring to ancestor objects and descendant objects in a display hierarchy.
i've just uploaded my notes for my session at fitc this sunday.
>> read notes for "ActionScript 3.0 and Flash CS3"
the lecture explains the new links between ActionScript 3.0 code and content created in Flash CS3. topics covered include the document class, linking symbols to classes, automatically generated classes, accessing on-stage instances from linked classes, and symbol instantiation.
Here are 12 paragraphs from Chapter 20 of Essential ActionScript 3.0.
20. The Display API and the Display List
One of the primary activities of ActionScript programming is displaying things on the screen. Accordingly, the Flash platform provides a wide range of tools for creating and manipulating graphical content. These tools can be broken into two general categories:
* The Flash runtime display API, a set of classes for working with interactive visual objects, bitmaps, and vector content
* Ready-made user interface components:
* The Flex framework’s UI component set, a sophisticated collection of customizable user-interface widgets built on top of the display API
* The Flash authoring tool’s UI component set, a collection of user-interface widgets with a smaller file size, lower memory usage, and fewer features than Flex framework’s UI component set
The display API is built directly into all Flash runtimes and is, therefore, available to all .swf files. The display API is designed for producing highly customized user interfaces or visual effects, such as those often found in motion graphics and games. This chapter focuses entirely on the display API.
The Flex framework’s UI component set is part of the Flex framework, an external class library included with Adobe Flex Builder, and also available in standalone form for free at: http://www.adobe.com/go/flex2_sdk. The Flex framework’s UI component set is designed for building applications with relatively standard user interface controls (scrollbars, pull-down menus, data grids, etc.). The Flex framework’s interface widgets are typically used in MXML applications, but can also be included in primarily ActionScript-based applications. For details on using the Flex framework in ActionScript, see Chapter 30.
The Flash authoring tool’s UI component set is designed for use with .swf files created in the Flash authoring tool, and for situations where file size and low memory usage are more important than advanced component features such as data binding and advanced styling options. The Flash authoring tool’s UI component set and the Flex framework’s UI component set share a very similar API, allowing developers to reuse knowledge when moving between the two component sets.
[SNIP]
DisplayObject, the root of the core-display-class hierarchy, defines the display API’s first tier of graphical functionality: on-screen display. All classes that inherit from DisplayObject gain a common set of fundamental graphical characteristics and capabilities. For example, every descendant of DisplayObject can be positioned, sized, and rotated with the variables x, y, width, height, and rotation. More than just a simple base class, DisplayObject is the source of many sophisticated capabilities in the display API, including (but not limited to):
* Converting coordinates (see the DisplayObject class’s instance methods localToGlobal() and globalToLocal() in Adobe’s ActionScript Language Reference)
* Checking intersections between objects and points (see the DisplayObject class’s instance methods hitTestObject() and hitTestPoint() in Adobe’s ActionScript Language Reference)
* Applying filters, transforms, and masks (see the DisplayObject class’s instance variables filters, transform, and mask in Adobe’s ActionScript Language Reference)
* Scaling disproportionately for “stretchy” graphical layouts (see the DisplayObject class’s instance variable scale9grid in Adobe’s ActionScript Language Reference)
Note that this book occasionally uses the informal term “display object” to mean “any instance of a class descending from the DisplayObject class.”
DisplayObject’s direct concrete subclasses—Video, Bitmap, Shape, MorphShape, and StaticText—represent the simplest type of displayable content: basic on-screen graphics that cannot receive input or contain nested visual content. The Video class represents streaming video. The Bitmap class renders bitmap graphics created and manipulated with the supporting BitmapData class. The Shape class provides a simple, lightweight canvas for vector drawing. And the special MorphShape and StaticText classes represent, respectively, shape tweens and static text created in the Flash authoring-tool. Neither MorphShape nor StaticText can be instantiated with ActionScript.
DisplayObject’s only abstract subclass, InteractiveObject, establishes the second tier of functionality in the display API: interactivity. All classes that inherit from InteractiveObject gain the ability to respond to input events from the user’s mouse and keyboard. InteractiveObject’s direct concrete subclasses—TextField, SimpleButton—represent two distinct kinds of interactive graphical content. The TextField class represents a rectangular area for displaying formatted text and receiving text-based user input. The SimpleButton class represents Button symbols created in the Flash authoring-tool, and can also be used to quickly create interactive buttons via ActionScript code. By responding to the input events broadcast by the TextField or SimpleButton the programmer can add interactivity to an application. For example, a TextField instance might be programmed to change background color in response to a FocusEvent.FOCUS_IN event and a SimpleButton instance might be programmed to submit a form in response to a MouseEvent.CLICK event.
InteractiveObject’s only abstract subclass, DisplayObjectContainer, is the base of the third, and final functional tier in the display API: containment. All classes that inherit from DisplayObjectContainer gain the ability to physically contain any other DisplayObject instance. Containers are used to group multiple visual objects so they can be manipulated as one. Any time a container is moved, rotated, or transformed, the objects it contains inherit that movement, rotation, or transformation. Likewise, any time a container is removed from the screen, the objects it contains are removed with it. Furthermore, containers can be nested within other containers to create hierarchical groups of display objects. When referring to the objects in a display hierarchy, this book use standard tree-structure terminology; for example, an object that contains another object in a display hierarchy is referred to as that object’s parent, while the contained object is referred to as the parent’s child. In a multilevel display hierarchy, the objects above a given object in the hierarchy are referred to as the object’s ancestors. Conversely, the objects below a given object in the hierarchy are referred to as the object’s descendants. Finally, the top-level object in the hierarchy (the object from which all other objects descend) is referred to as the root object.
Don’t confuse the ancestor objects and descendant objects in a display hierarchy with the ancestor classes and descendant classes in an inheritance hierarchy. For clarity, this book occasionally uses the terms “display ancestors” and “display descendants” when referring to ancestor objects and descendant objects in a display hierarchy.
DisplayObjectContainer’s subclasses—Sprite, MovieClip, Stage, and Loader—each provide a unique type of empty containment structure, waiting to be filled with content. Sprite is the centerpiece of the container classes. As a descendant of both the InteractiveObject the DisplayObjectContainer classes, Sprite provides the perfect foundation for building custom user interface elements from scratch. The MovieClip class is an enhanced type of Sprite that represents animated content created in the Flash authoring tool. The Stage class represents the Flash runtime’s main display area (the viewable region within the borders of the application window). And finally, the Loader class is used to load external graphical content locally or over the Internet.
Here are the first 8 paragraphs of Chapter 19 of Essential ActionScript 3.0.
19. Flash Player Security Restrictions
To protect data from being transferred to unauthorized destinations without appropriate permission, Flash Player scrutinizes all requests to load or access external resources, or interact with other .swf files or HTML files. Each request a .swf file makes for an external resource (a resource not compiled into the .swf file making the request) is rejected or approved based on the following factors:
* The ActionScript operation used to access the resource
* The security status of the .swf file performing the request
* The location of the resource
* The explicit access-permissions set for the resource as determined by either the resource’s creator or distributor
* The explicit access-permissions granted by the user (e.g., permission to connect to the user’s camera or microphone)
* The type of Flash Player running the .swf file (e.g., plug-in version, standalone version, Flash authoring tool test version)
In the preceding list, and throughout this chapter, the following terms have the following meanings:
Resource distributor
The party that delivers a given resource. Typically a server operator such as a web site administrator or socket server administrator.
Resource creator
The party that actually authors the resource. For .swf files, the resource creator is the ActionScript developer that compiles the .swf.
User
The user of the computer on which Flash Player is running.
This chapter explains Flash Player security restrictions in general terms, and then explores how security specifically affects loading content and accessing external data.
This chapter covers security restrictions in one specific Flash runtime: Flash Player (both the web browser add-on, and standalone player versions). For information on security limitations imposed by other Flash runtimes (e.g., Apollo and Flash Lite), see Adobe’s documentation.
Here are the first 5 paragraphs of Chapter 18 of Essential ActionScript 3.0
18. XML and E4X
Since Flash Player 5, ActionScript has included tools for working with XML-structured data. In ActionScript 1.0 and ActionScript 2.0, XML data was created and manipulated with the variables and methods of the built-in XML class (e.g., firstChild, nextSibling, appendChild(), etc.). The XML class was based on the W3C Document Object Model, or DOM, a standard for interacting with XML documents programmatically (see http://www.w3.org/DOM).
As of ActionScript 3.0, the toolset for creating and manipulating XML has been completely overhauled. ActionScript 3.0 implements ECMAScript for XML (“E4X”), an official ECMA-262 language extension for working with XML as a native datatype. E4X seeks to improve the usability and flexibility of working with XML in ECMA-262-based languages (including ActionScript and JavaScript).
Understanding XML Data as a Hierarchy
Before we can learn to manipulate XML data with E4X, we must first understand the general principle of XML as hierarchical data. Both the legacy XML class and E4X treat XML data as a hierarchical tree in which each element and text block is considered a tree node (i.e., a branch or a leaf). For example, consider the XML fragment in Example 18-1. (An XML fragment is a section of XML excerpted from an XML document.)
Example 18-1. An example XML fragment
<BOOK ISBN="0141182806">
<TITLE>Ulysses</TITLE>
<AUTHOR>Joyce, James</AUTHOR>
<PUBLISHER>Penguin Books Ltd</PUBLISHER>
</BOOK>
The elements <BOOK>, <TITLE>, <AUTHOR>, and <PUBLISHER>, and the text "Ulysses", "Joyce, James", and "Penguin Books Ltd" are all considered nodes on the tree, as depicted in Figure 18-1.
Here are the first 5 paragraphs of Chapter 17 of Essential ActionScript 3.0
17. Namespaces
In very general terms, a namespace is a set of names that contains no duplicates. That is, within the set, each name is unique. For example, in English, the names of fruits could be considered a namespace because each fruit has its own unique name—apple, pear, orange, and so on. Likewise, the names of colors could be considered a namespace because each color has its own unique name—blue, green, orange, and so on.
Notice that the name “orange” appears in both groups of names. The name “orange” itself is not unique, it is unique only within each group. Depending on whether you’re talking about a fruit or a color, the same name, “orange”, refers to two different things. That’s the purpose of namespaces. They let the same name (identifier) have different meanings depending on the context in which it is used.
When applied to programming, this “same name, different meaning” feature of namespaces offers two general benefits:
* It helps programmers avoid name conflicts
* It lets a program’s behavior adapt to the current context
Over the course of this chapter, we’ll explore the many nooks and crannies of namespaces in ActionScript. Try not to let the various details distract you from the relative simplicity of namespaces. Fundamentally, namespaces are nothing more than a two-part naming system. They are used to distinguish one group of names from another, much like an area code distinguishes one phone number from other phone numbers around the world.
Here are the first 7 paragraphs of Chapter 16 of Essential ActionScript 3.0
16. Scope
A scope is a physical region of a program in which code executes. In ActionScript there are five possible scopes:
* A function body
* An instance method body
* A static method body
* A class body
* Everywhere else (i.e., global scope)
At any specific point in the execution of a program, the availability of variables, functions, classes, interfaces, and namespaces is governed by the scope of the code currently being executed. For example, code in a function can access that function’s local variables because it executes inside of the function’s scope. By contrast, code outside the function cannot access the function’s local variables because it executes outside of the function’s scope.
In ActionScript scopes can be nested. For example, a function might be nested in an instance method, which, itself, is nested in a class body.
public class SomeClass {
public function someMethod ():void {
function someNestedFunction ():void {
// This function's scope is
// nested inside someMethod()'s scope,
// which is nested inside SomeClass's scope
}
}
}
When one scope is nested within another, the definitions (i.e., variables, functions, classes, interfaces, and namespaces) available to the enclosing scope become available to the nested scope. For example, a function nested inside an instance method can access that method’s local variables. The entire list of nested scopes surrounding the code currently being executed is known as the scope chain.
This chapter describes the availability of variables, functions, classes, interfaces, and namespaces within ActionScript’s various scopes.
Here are the first 6 paragraphs of Chapter 15 of Essential ActionScript 3.0
15. Dynamic ActionScript
ActionScript was originally conceived of as a language for adding basic programmatic behavior to content created manually in the Flash authoring tool. In early versions of ActionScript, most code was intended to be written in short scripts that implemented limited functionality compared with the code required to create a complex desktop application. As such, ActionScript’s original feature set stressed flexibility and simplicity over formality and sophistication.
ActionScript originally allowed the structure of all classes and even all individual objects to be modified dynamically at runtime. For example, at runtime, a program could:
* Add new instance methods or instance variables to any class
* Add new instance methods or instance variables to any single, specific object
* Create a new class entirely from scratch
* Change a given class’s superclass
With the advent of ActionScript 3.0, Flash Player 9, Apollo, and Flex, the Flash platform has evolved to a stage where the complexity of an ActionScript-based program may well rival the complexity of a full-featured desktop application. Accordingly, as a language, ActionScript has taken on many of the formal structures required for large-scale application development—structures such as a formal class keyword an inheritance syntax, formal datatypes, a built-in event framework, exception handling, and built-in XML support. Nevertheless, ActionScript’s dynamic features remain available in the language, and still constitute an important part of ActionScript’s internal makeup.
This chapter explores ActionScript’s dynamic programming techniques. Note, however, that the flexibility inherent in dynamic ActionScript programming limits or removes most of the benefits of type checking we studied in Chapter 8. As a result, most complex programs use the features described in this chapter only sparingly, if at all. For example, in the over 700 classes defined by the Flex framework, there are approximately only 10 uses of dynamic programming techniques. That said, even if you never intend to use dynamic programming in your code, the information presented in this chapter will improve your understanding ActionScript’s internal workings.
For our first dynamic programming technique, we’ll study dynamic instance variables—instance variables added to an individual object at runtime.
Here are the first 3 paragraphs of Chapter 14 of Essential ActionScript 3.0
14. Garbage Collection
Every time a program creates an object, ActionScript stores it in system memory (for example, in RAM). As a program creates hundreds, thousands, or even millions of objects, it slowly occupies more and more memory. To prevent system memory from being fully depleted, ActionScript automatically removes objects from memory when they are no longer needed by the program. The automatic removal of objects from memory is known as garbage collection.
Eligibility for Garbage Collection
In an ActionScript program, an object becomes eligible for garbage collection as soon as it becomes unreachable. An object is unreachable when it cannot be accessed directly or indirectly through at least one garbage collection root. The most significant garbage collection roots in ActionScript are as follows:
* Package-level variables
* Local variables of a currently executing method or function
* Static variables
* Instance variables of the program’s main class instance
* Instance variables of an object on the Flash runtime display list
* Variables in the scope chain of a currently executing function or method
Here are the first two paragraphs of Chapter 13 of Essential ActionScript 3.0
13. Exceptions and Error Handling
In this chapter, we’ll explore ActionScript’s system for generating and responding to runtime errors—or exceptions. In ActionScript, errors can be generated both by the Flash runtime and by the program that is executing. Errors generated by the Flash runtime are known as built-in errors; errors generated by a program are known as custom errors. In a program, we can respond to, or handle, any error (whether built-in or custom) using the try/catch/finally statement; we can generate an error via the throw statement.
To learn how to generate and respond to errors in a program, we’ll revisit our virtual zoo program.