Sponsored Link •
Frank Sommers: What is ActionScript?
We've done a few things differently from the ECMAScript standard, and the reason for that was that the standard wasn't actually finalized when we built Flash 9 and Flex 2. We had to make some assumptions about what things would be in the spec before the spec was ratified by the ECMAScript standards committee. As a result, there are probably a few slight variances between what we implemented in ActionScript 3 and the final ECMAScript specification, which, I believe, is still not final yet.Frank Sommers: What will surprise a Java developer the most when first encountering ActionScript 3 code? James Ward: Java developers will recognize and get to know the ActionScript 3 language very quickly. The syntax is very similar to Java's, and there are all the object-oriented features you're familiar from Java, such as extending classes and implementing interfaces.
The similar syntax allows Java developers to very quickly come up to speed by not having to really learn a brand new language. They can just focus on learning the slight differences from Java syntax, and learn how to actually use the ActionScript 3 language within the context of the Flash Virtual Machine.
One of the biggest differences from Java is optional static typing in ActionScript 3. When I came from Java to Flex, I was struck by the fact that I didn't have to type everything. I could type things, when I felt that typing was important, and when I wanted code hinting in the IDE, and compile and runtime type checking, but then there were places when typing didn't matter so much. There are places when you can leave things untyped or, to put it differently, dynamically typed. Optional typing made me have to do a bit of a mental shift from how I, as a typical Java developer, really saw languages.
There are just a few differences in syntax from Java. The package
declaration is almost the same, with the one difference that we put
curly braces inside the
package keyword, so when you define
a class, the class definition goes inside the curly braces within the
package declaration. Your
import statements go inside that
Instead of declaring methods, you explicitly have to say that
something is a function, with the
function keyword, and
your function's return types are specified with a colon after the
function name. Variables are defined with the
followed by the variable name, and then the type of the variable, if you
want to specify a variable type.
ActionScript has very similar namespaces to Java's:
you don't want something to be
protected, and want instead to
have your own name space that you can use internally, you can define
that namespace as well. If you have a variable, or an inner class, for
instance, that you only want to be accessed from, say, just two other
classes, then you can create a custom namespace and use that namespace
in just those two classes. That gives you more flexibility in how you
can structure your code. You can apply
protected, or any other name space you
create, on your class or a variable or a function. It's a bit different
from how you'd do that in Java, but once you get the hang of it, you can
get used to it and find it quite useful.
The Flex framework uses this technique pretty heavily. We have an
mx_internal namespace that we use for variables that we
think could change in the future and that you shouldn't rely on. But if
you did want to get access to one of these variables, you could import
mx_internal namespace, and then have access to the
variables in that namespace. By default, users don't see those
Function. You can define functions inline, for instance, for callbacks.
When you specify functions, a lot of times you may want to pull them out and use them as closure functions, and that's also available. Often, when you specify a listener in ActionScript 3, you would pass a function as the listener, which, in turn, will pass a reference to that function.
String, and the next variable can be dynamically typed. The Flex compiler will give you a warning, but the code will still compile and run just fine.
There are also keywords like
allow you to do casting on objects. If you wanted to find out what type
an object really was, you can do that through those keywords. In a
function call, for instance, you may not want to require a specific
type, but inside the function implementation you may want different
logic based on what type you were getting. In that case, you can find
out the object's specific type.
One of the places where you see the benefits of optional static typing is when you start pulling in Web services data that isn't SOAP, but come from RESTful or JSON-style Web services. You could go through all the work to type the whole response and convert everything into typed objects. But a lot of times the interfaces of the Web services that you're talking to aren't themselves very statically typed. Those interfaces don't necessarily follow a consistent object model.
That's one place where I typically don't force my objects into being statically typed. When you talk to the Flikr API, for instance, and you decided to define a bunch of objects that represent their API, if Flikr changes the data their API exposes, you would have to change your object model, too. Static typing may not buy you much in that case. With dynamic typing, as long as they used the same names, everything would continue to work.
Flex takes advantage of optional static tying in a couple of places. Flex defines an HTTP Service, for instance. [Editor's note: The HTTP Service is an object-oriented client-side HTTP API.] You can get back your response from the HTTP Service in a couple of different ways. The default way is to take all the XML you get back from a RESTful service call, and deserialize that response into basic objects: not typed objects, but objects that are basically just hashmaps or name-value pairs. You can also have the HTTP service give you back E4X objects, which is ActionScript's XML API. You can then execute XPath-style queries on that response, for instance. And you can also write your own custom deserializer to go through the XML tree and deserialize that into typed ActionScript objects.
One way to think about optional static typing is by comparing it to untyped Java collections. You can stick any type object into a collection, and then cast that object back into its type when you need to know the specific object type.
In Flex, if you define a variable to be of type
then you can set any property you want on that object. You don't have to
specify in advance the properties of that object, but can, instead, go
in and arbitrarily set properties on the object. If you create an
instance of an object
foo, you can just say,
foo.name = "a new String". That would set the
name property on that object, even though you never defined
name property for that object before. You can also add
functions to an object in a similar way: You can just say,
foo.doSomething = something, where
is a specification of a function.
Frank Sommers: You mentioned E4X, ActionScript's native XML support. What advantages does E4X provide over other XML processing APIs?
James Ward: XML is a native data type in ActionScript 3. One way we support XML is through E4X, which is an ECMA standard, and is part of the ECMAScript language. We chose to follow the standard instead of creating our own XML support in the language. E4X is an XQuery- and XPath-like language for manipulating XML structures. The query language built into E4X makes it easy to find elements, or collections of elements, in your XML tree, pull elements out, or set and add elements to XML structures.
ActionScript, and Flex, also have facilities to take ActionScript
objects and serialize them into XML and back. While E4X is very powerful
and convenient for many XML-related tasks, you have the choice of
whether to deal with
XML objects, or whether to serialize
XML objects into your ActionScript objects, and then use those
ActionScript objects in your code. Those with a Java background may find
the latter more natural. But once you get used to E4X, you may find it
very convenient, too.
The Flex framework classes define the containers, layouts, and controls, and are all implemented in ActionScript. The source code for the whole Flex framework is shipped with the Flex SDK. You can go in and see how all of those components are built, and you can extend those components as well with ActionScript code.
It's also possible to not use anything that Flex provides, and just build from scratch your own ActionScript rich-client framework. You could conceivably build anything you'd want on top of the Flash Player DOM, using Flash Player's ability to draw lines, do vector graphics, and use all the things that the Flash VM can do. All the Flash animations you see people do on the Web are built to run on the Flash VM, so you can conceivably go in and use the low-level drawing APIs to create animations, draw lines with nice anti-aliasing, display and record video, and so on.
But you don't have to do that, because Flex gives you all the components built for you, including very rich UI controls, such as a data grid. In your application, you can just create an instance of the data grid, for example, and then you can override any of the methods in that component, including default styles and properties.
The Flex components use the low-level Flash API to draw lines, and basically take advantage of the rich media capabilities of the Flash VM. With the Flex API, you're programming at a higher level, and don't have to learn the low-level details of how the components and effects are actually implemented.
At the same time, one difference from Swing, for instance, is that with Flex you could go really low-level, if you wanted to, because those low-level Flash API calls are available to any Flex application. You could even mix high-level Flex API calls with low-level Flash API calls. If you didn't like how something looked in Flex, you could go in and do some lower-level graphics calls to change how a component looked. You could also use that technique to set custom item renderers, too. In practice, you will very rarely, if ever, need to do that because Flex exposes a very rich set of component properties.
The other differences from Java come from the media-handling capabilities of the Flash VM, such as video and audio playback capabilities. Media support has been built into the Flash player for a long time now, and that's one of the areas where the Flash VM really shines. Flash was built with the idea to allow people to create multimedia experiences on the Web. Flex applications can easily take advantage of all those rich-media capabilities.
Video and audio integration with the Flex API is very simple and
straightforward. If you wanted to have your Web cam record some video
and broadcast that video out to other computers, that takes only a few
lines of code to accomplish in Flex. You just find the
Camera object in the API, and call a few methods on that
object. Playing back video is similarly simple: You can use the
VideoDisplay object, and point that to a URL. Out of the
box, we support the FLV format, which is Flash Video, the SWF format,
which is the regular Flash format, and MP3 playback.
Adobe's Flex SDK http://www.adobe.com/products/flex/
An online Flex compiler http://try.flex.org
Flex.org, the Flex community site http://www.flex.org
A Flex component explorer http://examples.adobe.com/flex2/inproduct/sdk/explorer/explorer.html
The ECMAScript4XML (E4X) Specification http://www.ecma-international.org/publications/standards/Ecma-357.htm
The Mozilla ECMAScript 4 Proposal http://www.mozilla.org/js/language/es4
Frank Sommers is Editor-in-Chief of Artima Developer. He also serves as chief editor of the IEEE Technical Committee on Scalable Computing's newsletter, and is an elected member of the Jini Community's Technical Advisory Committee. Prior to joining Artima, Frank wrote the Jiniology and Web services columns for JavaWorld.