Học Actionscript 3.0 - p 41 docx

Communicating with Loaded SWFs
Chapter 13: Loading Assets
379
maximum, and default. We’ve set the maximum to 50, and the default to
0, and we’re incrementing the minimum by 1 every enter frame. When the
value reaches 50, the event listener is removed, halting the animation (lines
62 through 65).
56 //adjust filter values
57 private function onEnter(evt:Event):void {
58 _penguins.filters = [_shaderFilter];
59
60 _val++;
61 _shader.data.amount.value = [_val, 50, 0];
62 if (_val >= 50) {
63 this.removeEventListener(Event.ENTER_FRAME,
64 onEnter);
65 }
66 }
67 }
68 }
Communicating with Loaded SWFs
Now that you know how to load SWFs, let’s talk about communicating
between them. For this discussion, we’ll reference the
Loader class, but the
ideas in this section apply equally to the
CustomLoader class.
The key to communicating between a parent SWF created with ActionScript
3.0 and a loaded SWF created with ActionScript 3.0 is understanding the posi-
tion of the
Loader instance between the two SWFs. Within the parent, access-
ing the child SWF is straightforward because you need only do so through

the
Loader instance. The same is true in the other direction, from child to
parent, but is less obvious to some. Just like when traversing the display list,
you can use
this.parent within a loaded child SWF to talk to its parent.
However, this will refer to the
Loader instance, not the SWF’s main timeline
(or document class) scope.
The following examples, found in the communication_parent.fla and com-
munication_child.fla source files, demonstrate several tasks you may need to
perform when communicating between parent and child SWFs, including
getting or setting properties, calling methods, and calling functions. This
exercise shows communication in both directions. Both SWFs contain a
simple movie clip animation, a function, and a variable. They both trace
information to help you understand what’s happening when the parent SWF
loads the child SWF into a
Loader instance.
The child SWF
Lines 1 through 7 provide the code that is self-contained within the child
SWF, which the parent will manipulate. Line 1 initially stops the animation
so we can demonstrate the parent calling the
MovieClip play() method. We’ll
show you when this occurs in the parent script, but after loading, the anima-
tion should play. Line 3 creates and populates a string variable, the content
N OT E
To see the CustomLoader class used in
this context, consult the nearly identical
source files, communication_child_cus-
tom.fla and communication_parent_
custom.fla. For these examples to work,

the child SWF must exist before testing
the parent SWF.
N OT E
SWFs created with ActionScript 3.0 can-
not talk directly to SWFs created with
ActionScript 2.0 or ActionScript 1.0. If
you must do this, such as when show-
casing legacy projects in a new portfolio
site, you can do so with a workaround
that establishes a
LocalConnection
channel between the SWFs. For more
information, see the “Sending Data from
AVM2 to AVM1” post on the companion
website.
Download from Wow! eBook <www.wowebook.com>
Part V: Input/Output
380
Communicating with Loaded SWFs
of which states that it exists inside the child SWF. Lines 5 through 7 define a
function that traces a string passed to it as an argument. This string will orig-
inate in the parent SWF to demonstrate calling a function in the child SWF.
Lines 9 through 25 contain the inter-SWF communication, but the condi-
tional beginning in line 9 is necessary to prevent errors when testing the SWF
prior to loading. The conditional simply checks to see if the parent of the
SWF’s main timeline is the stage. As we discussed in Chapter 4 when cover-
ing the display list, there is only one stage and, when a SWF is on its own, its
parent is the stage. If this is true, the child will trace [object Stage] in line 11,
and show that the stage has no other parent by tracing null in line 12. We’ll
discuss what happens when the SWF’s parent is not the stage after the code.

1 childAnimation.stop();
2
3 var stringMsg:String = "STRING INSIDE CHILD";
4
5 function childFunction(msg:String):void {
6 trace("traced from function within child:", msg);
7 }
8
9 if (this.parent == this.stage) {
10 trace("child without being loaded:");
11 trace(" my parent:", this.parent);
12 trace(" my parent's parent:", this.parent.parent);
13 } else {
14 trace("child communicating with parent:");
15 var parentLoader:Loader = Loader(this.parent);
16 var parentApp:MovieClip = MovieClip(this.parent.parent);
17 trace(" my parent:", parentLoader);
18 trace(" getting my parent's property:", parentLoader.x);
19 trace(" my parent's parent:", parentApp);
20 parentApp.stringMsg = "NEW STRING INSIDE PARENT";
21 trace(" my parent's parent's redefined variable:",
22 parentApp.stringMsg);
23 parentApp.parentFunction("message from child");
24 parentApp.parentAnimation.play();
25 }
If the child SWF’s parent is not the stage, lines 15 and 16 cast the parent to
a
Loader instance and the parent’s parent (which is the main timeline of
the SWF doing the loading) to a
MovieClip instance. Line 17 then traces the

Loader instance, and line 18 traces a property of that Loader. Line 20 demon-
strates setting a variable in another SWF by changing the string variable in
the parent. (We’ll see that variable in a moment, but it’s equivalent to line 3
in the child). Lines 21 and 22 then get and trace that variable. Finally, line 23
calls a function in the parent (passing a string argument in the process), and
line 24 plays the movie clip in the parent.
The parent SWF
The parent SWF requires no conditional, but is responsible for loading the
child SWF. Lines 1 through 7 perform similar roles to the corresponding lines
in the child SWF—initially stopping a movie clip animation, declaring and
Download from Wow! eBook <www.wowebook.com>
Additional Online Resources
Chapter 13: Loading Assets
381
populating a string variable, and defining a function that accepts a string as
an argument. The variable in line 3 is the same one redefined by the child
SWF in its line 20, and the function in line 5 is the same one called by the
child SWF in its lines 21 and 22.
Lines 9 through 15 should be familiar territory by now. They create a
Loader
instance, add it to the display list, load the child SWF, and create a
COMPLETE
event listener that calls the function in line 16 when the event is heard. Line 17
casts the content of the
Loader (the child SWF) as a MovieClip, line 19 traces
the child SWF’s variable, line 21 calls the child SWF’s function, and line 22
plays the child SWF’s movie clip.
1 parentAnimation.stop();
2
3 var stringMsg:String = "STRING INSIDE PARENT";

4
5 function parentFunction(msg:String):void {
6 trace("traced from within parent:", msg);
7 }
8
9 var ldr:Loader = new Loader();
10 addChild(ldr);
11 ldr.load(new URLRequest("communication_child.swf"));
12
13 ldr.contentLoaderInfo.addEventListener(Event.COMPLETE,
14 onComplete,
15 false, 0, true);
16 function onComplete(evt:Event):void {
17 var childSWF:MovieClip = MovieClip(ldr.content);
18 trace("\nparent communicating with child:");
19 trace(" getting my child's variable:",
20 childSWF.stringMsg);
21 childSWF.childFunction("message from parent");
22 childSWF.childAnimation.play();
23 }
Additional Online Resources
We want to wrap up by drawing attention to two important loading-related
issues that we’ve documented in detail online. The first is a workaround
for a problem that occurs when loading SWFs that contain Text Layout
Framework (TLF) assets (discussed in Chapter 10). The second is a third-
party ActionScript package called LoaderMax that brings a lot of power and
convenience to the loading process.
Loading SWFs with TLF Assets
TLF uses a Runtime Shared Library (RSL)—an external library of code with
an .swz extension that’s loaded at runtime. If a user doesn’t already have the

correct version of the RSL on his or her computer, the TLF asset will try to
download it from the Adobe website. Failing that, a version of the RSL from
the same directory as the SWF will be loaded.
N OT E
The source files communication_par-
ent_custom.fla and communication_
child_custom.fla replicate the scripts in
this section but use the
CustomLoader
class for all loading.
The companion website also contains
an example of communication between
parent and child SWF without using
a
Loader instance. See the post “SWF
Communication without Going Through
Loader.”
N OT E
Runtime shared libraries can have a
.swz extension if compressed, and a .swc
extension if not compressed.
Download from Wow! eBook <www.wowebook.com>
Part V: Input/Output
382
Additional Online Resources
Because RSLs are external, it’s possible to experience a short delay when view-
ing TLF assets. (Ideally this occurs only the first time, as RSLs should be cached
on your computer thereafter.) To compensate for this possible delay, Adobe
included a preloader that’s automatically added to any SWF that uses TLF.
Unfortunately, this setup causes problems after loading SWFs with TLF

assets. The most common problem is that you can’t communicate between
parent and child, as described in the “Communicating with Loaded SWFs”
section of this chapter, because of the extra layers of loaders that are inserted
into the display list by the TLF asset.
There are essentially two solutions to this problem, both of which are dis-
cussed on the companion website in the “Loading SWFs that Use TLF” post.
The first is to compile the TLF Runtime Shared Library code into your SWF.
This makes the entire setup internal, but also increases your SWF’s file size
by about 120k. The second solution is to use Adobe’s new
SafeLoader class.
The
SafeLoader class is a replacement for the Loader class (it doesn’t extend
Loader) and is available for download from the following Adobe Technote:
Its use is nearly identical to
the
Loader class, and you only really need to use it when you know you’re
loading TLF assets. Sample code is provided with the class in the cited down-
load. We’ll also use it in the XML navigation bar in Chapter 14.
The
SafeLoader class was released soon after Flash Professional CS5 was
released and may still have some issues to grapple with. We discuss such
issues in the aforementioned companion website post, so be sure to review it
before using the class.
TLF assets also affect preloading code designed to preload the SWF in which
the code resides. That is, instead of loading an external asset, this kind of
preloading code sits in frame 1 of the SWF and loops back to frame 1 until
the SWF is fully loaded. Once the SWF is loaded, the code then moves the
playhead on to the next frame.
GreenSock’s LoaderMax
A fitting end to this chapter is a quick blurb about LoaderMax. Brought to

you by GreenSock, the makers of TweenLite, LoaderMax is the crème de la
crème of ActionScript 3.0 loading libraries. Adding as little as 7k to your
SWF (depending on which classes you need to use), LoaderMax loads SWFs,
images, XML, videos, MP3s, CSS, data, and more. LoaderMax simplifies and
enhances loading the way TweenLite simplifies and enhances tweening. For
example, here are some of the things LoaderMax can do:
N OT E
If you ever see an animated line of five
dots before a TLF asset displays, that’s
its preloader at work.
N OT E
Flash Professional CS5 users can see
an example of a self-preloader in the
templates that ship with the applica-
tion. Select the File
→New menu option,
and then select the Templates tab in the
dialog box that appears. Choose the
Sample Files category and select the
Preloader for SWF template. You can
then see the preloading code in frame 1.
If you are not using Flash Professional
CS5, you can search the web using the
phrase “AS3 preloader internal” for
many examples to find one that suits
your coding style. Because links change
often, the companion website will pro-
vide a link to both a class-based and
timeline-based example in the cited post.
Download from Wow! eBook <www.wowebook.com>

Additional Online Resources
Chapter 13: Loading Assets
383
• Build loaders in a variety of ways, including single-item loaders from
nothing more than a
String path (LoaderMax can automatically deter-
mine which type of loader to use based on the file extension) and loader
queues automatically assembled from XML documents
• Build a queue that intelligently loads assets in the order specified but that
can easily reprioritize the queued assets on the fly
• Show progress of individual loaders or all loaders as a group
• Easily add robust event listeners, including multiple events in a single
line of code
• Integrate subloaders (LoaderMax instances that exist inside an asset
being loaded) with the overall progress and event model of the main
loader
• Provide an alternate URL that will automatically be used in the event the
first URL fails
• Pause and resume loads in progress
• Circumvent existing ActionScript loading and unloading issues with
improved garbage collection, including properly loading SWFs with TLF
assets
• Optionally manipulate many display characteristics include automatic
scaling, image smoothing, centering registration points, and more
• Operationally control video and MP3 assets, including methods that play,
pause, and go to specific time; properties that get or set volume, time, and
duration; and events that monitor playback progress and more
• Provide a substantial number of shared properties, methods, and events
to all loader types improving consistency and saving lots of manual labor.
LoaderMax is easy to learn and use, particularly after you’re familiar with the

ActionScript 3.0 loading process. Ideally, this chapter has provided you with
the groundwork to get you started, and you can consider using LoaderMax
for your next project. For more information, visit .
learningactionscript3 Package
The contributions from this chapter to our ongoing package of ActionScript classes
include
CustomLoader
(for loading SWFs and images) and
CustomURLLoader
(for
loading text, URL variables, and binary data).
N OT E
See the “Meet LoaderMax” post at the
companion website for additional infor-
mation and source code.
Download from Wow! eBook <www.wowebook.com>
Part V: Input/Output
384
What’s Next?
What’s Next?
Throughout this book, we’ve demonstrated a few examples of loading exter-
nal assets. Previously, we discussed loading HTML and CSS (Chapter 10),
sound (Chapter 11), and video (Chapter 12). In this chapter, we focused on
loading SWF and image assets, as well as text, URL variables, and binary
data. We also extended the
Loader and URLLoader classes to add some basic
diagnostic features to make it easier to check on your loading efforts. Finally,
we discussed communication with loaded SWFs and provided a few online
resources that touch on additional loading-related topics. With this informa-
tion as a head start, you should be able to begin working with just about any

basic external asset, and begin explorations into intermediate and advanced
loading issues.
Next we’re going to cover XML, which is among the most important stan-
dard formats used for data exchange, and E4X, the dramatically simplified
approach to working with XML in ActionScript. XML is very widely used and
enables a significant leg up over name-value pairs when it comes to struc-
tured data and large data sizes.
In the next chapter, we’ll cover:
• The basics of the XML format
• Reading, writing, and editing XML data
• Loading XML assets using the
CustomURLLoader class from this chapter
• XML communication with servers and other peers
Download from Wow! eBook <www.wowebook.com>
385
IN THIS CHAPTER
Understanding XML
Structure
Creating an XML Object
Using Variables in XML
Reading XML
Writing XML
Deleting XML
Loading External XML
Documents
Sending to and Loading
from a Server
An XML-Based Navigation
System
What’s Next?

XML, which stands for Extensible Markup Language, is a structured, text-
based file format for storing and exchanging data. If you’ve seen HTML
before, XML will look familiar. Like HTML, XML is a tag-based language.
However, it was designed to organize data, rather than lay out a web page.
Instead of a large collection of tags that define the language (as found in
HTML), XML is wide open. It starts with only a handful of preexisting tags
that serve very basic purposes. This freedom allows you to structure data in
a way that’s most efficient for your needs.
In the past, traversing and working with XML within ActionScript has not
been the most pleasant or efficient of experiences. Fortunately, E4X (which
stands for ECMAScript for XML), is a part of ActionScript 3.0. E4X is the
current standard for reading and writing XML documents and is maintained
by the European Computer Manufacturers Association. It greatly reduces the
amount of code and hoop-jumping required to communicate with XML. It
allows you to treat XML objects like any other object with familiar dot syn-
tax, and provides additional shortcuts for traversing XML data. You can use
ActionScript’s E4X implementation to create XML inside a class or the Flash
timeline or, more commonly, load an XML file at runtime.
In this chapter you’ll learn the essentials of E4X, and other XML-related con-
cepts. We’ll cover:
• Understanding XML Structure. The flexibility of XML means you can
set up files in a manner that best serves your project’s requirements. Unlike
other tag-based languages, there’s no library of tags to memorize—just a
few simple rules to follow.
• Creating an XML Object. To learn how to read and write XML, you
must first be able to create an XML object. We’ll show you how to create
an object directly from XML nodes and from parsing a string. Later, we’ll
show you how to load XML from an external file.
• Using Variables with XML Nodes. Both when creating an XML object
and when writing XML on the fly, you can use variables when building

xmL
CHAPTER
14
Download from Wow! eBook <www.wowebook.com>
Part V: Input/Output
386
Understanding XML Structure
nodes. This gives you the same latitude to manipulate XML on the fly
using stored information that you enjoy when working with other data.
We’ll also review basic variable practice to build a string, which can then
be parsed, or analyzed, as XML.
• Reading XML. Reading and parsing XML files is significantly easier
using E4X than when using prior versions of ActionScript. You can
find specific pieces of information, as well as sweep through the entire
document, using properties and methods that are consistent with other
ActionScript objects.
• Writing XML. You can also put the same power, clarity, and ease of use
to work when creating XML. You can create XML for internal use or build
data structures for use with servers or other clients.
• Deleting XML. Whether eliminating unwanted items during reading to
simplify the final XML object or removing errant elements when writing,
it is sometimes necessary to delete elements.
• Loading External XML Documents. Because you determine its struc-
ture, XML is highly efficient and often the format of choice for portable
data. As a result, external XML documents are very useful for loading
data at runtime.
• Communicating with XML Servers. After learning how to read and
write XML, you can then use it in your communications between servers
and other clients.
• An XML Navigation System. We’ll enhance the navigation system cre-

ated in Chapter 6, reading the menu content from XML instead of an
array. We’ll also populate a
Loader instance so you can use the menu to
load external SWFs and images.
Understanding XML Structure
When working with large data sets, XML is a vast improvement over the
name-value pairs that are used in simple web communications, such as
HTML forms. An XML document can contain much more data, but can
also convey an information hierarchy, detailing relationships among data
elements. For example, you can organize a list of users—with names, emails,
passwords, and similar information—much the way you would a traditional
database. Records might be represented with tags (called element nodes in
XML) that define a single user, similar to a database record; nested, or child,
tags might serve as the equivalent of database fields, associating data with
that user. Element nodes can contain text, which is also considered an XML
node (a text node) for easy parsing. Once you establish a structure, you can
duplicate a tag set any time a new record (or user, in this case) is added, and
the consistent structure can be reliably navigated when retrieving the data.
Download from Wow! eBook <www.wowebook.com>
Understanding XML Structure
Chapter 14: XML
387
Here is an example XML document:
<users>
<user>
<username>johnuser</username>
<email></email>
<password>123456</password>
</user>
<user>

<username>janeuser</username>
<email></email>
<password>abcdef</password>
</user>
</users>
Because you make up the tags as you go along, this document would be just
as valid if you replaced the word “user” with “student” throughout. Neither
the data nor the data structure would change. The document simply might
be more meaningful if you were describing students instead of users.
The easiest way to understand this open format is to remember that XML
simply structures your content. While HTML defines the layout of a web
page and gives instructions for displaying that page to a browser, XML does
nothing more than organize data. It’s up to the application to correctly parse
the data. Think of XML as you would any other structuring effort. For exam-
ple, you might export text from a database or a spreadsheet using XML as
a replacement for comma-delimited or tab-delimited formats (records sepa-
rated by carriage returns, fields separated by commas or tabs, respectively).
There are only a few simple rules to remember when you’re creating an XML
document:
• Every XML document must have a root node that contains all other infor-
mation. It doesn’t have to have a specific name, but all XML data must be
nested within one node.
• XML is case-sensitive. It doesn’t matter whether you use lowercase or
uppercase, but the case used in matching opening and closing tags must
be consistent. There are two schools of thought when it comes to choos-
ing a case. The first school advocates uppercase as a means of making it
easier to separate tags from content when you glance at the document.
The other school pursues lowercase as a de facto standard form used in
programming, URLs, and other places where case sensitivity matters.
• All nodes must be closed—either with a balancing tag or as a self-closing

tag. Balancing tags must be written as
<one>text</one> versus <one>text.
Single tags (such as a line break,
<br>, in HTML), must use the self-
closing format—preceding the last greater-than symbol with a slash (such
as
<br />).
• All tags must be properly nested. The following is incorrect:
<one><two>term</one></two>. But this is correct: <one><two>term</two>
</one>
.
N OT E
As a personal preference, we opt for
lowercase. You’ll learn later in this
chapter how you can address XML ele-
ments using dot syntax the same way
you would create custom properties
of objects, as described in the section
“Custom Objects” section of Chapter
2. However, case sensitivity must be
preserved. Therefore, a node called
username in lowercase would be repre-
sented as
<username>, while uppercase
requires
<USERNAME>. We prefer to
reserve uppercase in ActionScript as a
convention for representing constants.
Download from Wow! eBook <www.wowebook.com>
Part V: Input/Output

388
Understanding XML Structure
• All attributes must be enclosed within quotation marks. The following
would generate an error:
<story class=headline>News</story>. But this
will not:
<span class="headline">News</span>. This is important not only
because the XML must be well formed, but because attributes are also
XML nodes and can be parsed just like element and text nodes.
A few other items that warrant a bit more discussion are covered in the fol-
lowing sections.
White Space
White space includes all returns, tabs, and spaces between tags, as indicated
in the example below:
<users>
<user>
<username>johnuser</username>
<email></email>
<password>123456</password>
</user>
</users>
By contrast, the following example has no white space:
<users><user><username>richshupe</username><email>
</email><password>123456</password></user></users>
Both are representations of the same document, and they each have their
benefits. The file size of the version with no white space is a tiny bit smaller
due to the reduced number of characters; however, in all but very large docu-
ments, this is usually negligible. The version with white space is much easier
to read.
White space is important to understand because this information could be

interpreted as text. Return, tab, and space characters are all legal text entities,
so the XML parser must be told to ignore them or they will be counted as
such when reading the document. This is because tags and text are separate
objects when parsed. The tags are called element nodes and the text entries
within the tags are called text nodes. Because the white space can be inter-
preted as text nodes, the previous XML examples would contain a different
number of nodes with and without white space.
Readability usually prevails when formatting XML documents and, fortu-
nately, ignoring white space is the default behavior of ActionScript’s E4X
implementation. To parse white space, you must add this static property set-
ting to your script before creating your XML object.
XML.ignoreWhitespace = false;
N OT E
We strongly recommend against this
unless you have a pressing need to parse
the whitespace. If you choose not to
ignore whitespace, every discrete run of
space, tab, and return characters will be
interpreted as a text node.
Download from Wow! eBook <www.wowebook.com>