Unless you’ve been writing code from the underside of a rather sizable boulder over the last four years or so, the concept of "rich Internet applications", or "RIAs" to all the cool kids, crossed your developer radar sometime before now. If you’re one of those aforementioned subterranean developers, I leave it to your Google skills to discover the official definition of RIA; for now, presume that it means having a user interface that is one designed to be more functional and/or performance-minded than the traditional Web application, with its "type an address, wait for the network to deliver a Web page, fill out the form, click a button, wait for the network to deliver another Web page" interaction cycle. AJAX is one such RIA, Silverlight is another, but all of them were predated by Adobe’s Flash long before.
Because of their novelty, much of the RIA emphasis squarely focused on tools like AJAX and plain-old-JavaScript, but Apple’s sudden and dramatic rise to dominance in the mobile-device market in the last three years challenges all that. It’s not enough to just have a Web application that assumes the latest in browser technology and a broadband connection that rivals the US Government’s own. In fact, even with that browser and fast connection, developers working on Web applications that want to go beyond the basics of HTML suddenly find themselves drowning in a sea of conflicting browser implementations, network latency, scores of JavaScript libraries, and mismanaged user expectations.
Genesis... of a personal sort
As a developer who’s spent most of his professional life worrying more about the back end, I’ve never given much love to the tools and technologies used by the developers working on the front end of my applications. In fact, I’ve been prone to dismiss the whole thing, calling most of that side of application development "nothing more than watching pixels change color". Not the most flattering of phrases, I admit, but let’s be honest: up until the last couple of years, traditional application UI development wasn’t exactly the world’s most stimulating conversations: put up a form, let the user type some stuff in, then submit it back to the server, where we back-end guys would do the heavy lifting. Said lifting consisting, of course, of all the work validating all the input (in case the user was actually a hacker trying to use Telnet to fake us out by pretending to be a browser and yet still skipping all that "wonderful" JavaScript validation logic), making a few database and/or Web Service calls, possibly even in parallel, gathering up some templating or view-generating technology to prepare the assorted HTML, CSS and JavaScript fragments that needed to be sent back, assembling them, and shipping them back to the browser for rendering and display.
Good times.
Recently, though, several things have come in front of me that require me to take a new look at the state of the UI world:
- The mobile device market-the iPhone, Android and even Windows Phone-has heated up to the point that ignoring it pretty much signals your imminent retirement from software development. Much as I might want to retire, that doesn’t look financially feasible for a while, not with two kids ready to head off to college.
- Speaking of kids, my eldest son is deeply interested in becoming a game developer, and is interested in the two of us working on a game idea or two together. Games, of course, are not traditionally subjects for us big-name "enterprise" development types... but in addition to just wanting to spend some time with my son, "gamification" is quickly becoming a hot term among the Web-savvy and marketing folks, and thus worth exploring a bit more.
- Speaking of games, games have an interesting set of problems: they have very different kinds of communication and presentation requirements than traditional form-based apps. Games aren’t alone in this, though--there’s more than a few business applications that could benefit from faster response times or even some kind of offline-execution strategy. Much as we’d like to assume that every user will have an always-on broadband connection, the stark reality is that airplanes with Internet connectivity are still rare, hotel ISPs tend to disappear for no reason, and good conference wireless remains an all-too-elusive treasure. In fact, it’s fair to say that the more we see network connectivity rolled out into various places, the more it seems good connectivity is hard to find. And that seriously jeopardizes the efficacy of traditional browser clients.
- Last but not least, Adobe approached me, asking if I was interested to explore Flex from a Java guy’s perspective, to have a hard look at it and write up the results. As a matter of principle, full disclosure requires me to state that they are paying me to write these articles, but as a matter of personal honesty, I’ve been looking for an excuse to spend some quality time with Flex, so their offer put me "over the top", so to speak.
The plan, then, is to do exactly that: a column, hosted here on InfoQ, to put Flex through its paces from the perspective of the Java-first guy (as opposed to the artsy turtleneck-wearing earring-bedecked web design Flash-storyboarding guy), looking at it not just from the traditional plain-gray business app perspective, but from all sorts of different angles, including that of games/gamification, integration with existing Java applications, and its applicability for use as a mobile device client technology.
Shall we?
Getting Started
The Flash platform (the basis for Flex) is almost as ubiquitous as the browser itself, having been installed into browsers all over the world for nigh-on a decade now. It began as a way to bludgeon the unwary with lovely little animation shorts, video clips, and the odd game, all from within the browser. For years, this remained the only way to do anything beyond the stock HTML specification, aside from the Java applet, which had its own share of issues and problems. Granted, it required a native plugin, but that was considered the cost of doing business, and most users put up with the one-time download to see the dancing hamsters or play the cute casual game.
Unfortunately, Flash itself remained outside the reach of most developers, since it was designed from the outset to be easily accessible to "creative" types, using concepts found among the artsy set, such as storyboards, timelines, animation effects, and so on. Nary a form field, object model, or core validation logic component to be found anywhere. This meant that if a developer was going to make use of the platform, they had to make use of foreign-looking tools, unfamiliar terminology, and a user community that sipped espressos instead of pounding Mountain Dew.
Despite that exterior, the Flash platform has always borne a remarkable resemblance to its Java-based cousin: a bytecode-based execution engine, ported to a variety of different platforms. (In many ways the Flash plugin represents the answer to the "what if?" of Java’s write-once-run-anywhere client-side existence.) Instead of .class or .jar files, Flash executes .SWF ("swiff") files, laid out in a publicly-documented format, just as .class files are. And a few years ago, Adobe took the step of opening up the platform to developers by providing Flex, a set of tools designed to make it easier for developers to build SWFs without the artsy-oriented Flash tool.
Thus, the first step would be to obtain said SDK, found at Adobe’s website at << URL >>. Casual observation will reveal that Flex has a couple of different downloads, the major difference between them being the licensing models attached to each-the larger download, the "Adobe Flex SDK", contains software under Adobe’s own Open-Source license, which may not be acceptable to some organizations, so Adobe makes an alternative bundle, the "Open Source Flex SDK", which is Mozilla-licensed (MPL). Generally, unless your organization is particularly strict about such things, the full "Adobe Flex SDK" bundle is good for developer research and prototyping, but lawyers should have a look at the licensing before you consider going to production. The recently-released Flex 4.5 SDK will be our working platform; if you haven’t already, take moment and pull it down.
Once retrieved, the SDK is simply a ZIP file, easily unpacked into a convenient location on your hard drive, preferably someplace close to the other development tools in your life. On my system, I tend to put all my tools under a "prg" directory, so on my Windows box it rests at "C:\Prg\flex-4.5"; see Figure 1-1. Inside that directory, we find a slew of tools and files, using a directory structure that looks fairly familiar to developers who’ve looked at a JDK installation directory before. The "bin" directory will be where the tools developers love are stored (and should thus be on the PATH), "samples" will be where various example apps live, and so on.
Figure 1-1
(One cautionary note: the "env.bat" file seen in the directory listing in Figure 1-1 is of my own creation, used to make it easy to get a command-line environment quickly set up for doing Flex development; it’s a simple batch file to set the PATH and title the terminal window, so under Windows it looks like Figure 1-2. It also assumes your JDK and related tools are already set up in that same terminal window.)
Figure 1-2
@SET ANT_HOME=C:\prg\apache-ant @SET JAVA_HOME=C:\prg\jdk_1.6.0 @SET FLEX_HOME=C:\prg\flex_sdk_4.5.0.20967 @PATH=%FLEX_HOME%\bin;%ANT_HOME%\bin;%JAVA_HOME%\bin;%PATH% @TITLE Flex 4.5 Prompt
The quickest and easiest way to see if Flex is good to go on your box is to give one of the "bin"-based tools a spin, and the one we’ll get to know soon enough is the Flex compiler, mxmlc. So assuming C:\Prg\flex-4.5\bin is already on the PATH, just fire it up ("mxmlc") and see if it responds; assuming all is good, you should see the traditional compiler "I didn’t really do anything" response, a la Figure 1-3.
Figure 1-3
Show me the Code (And Tools)!
The first program that any developer must write in a new platform is always "Hello World", not only because it serves to pay proper respect to our ancient ancestors (Kernighan and Ritchie), but because it demonstrates the simplest program we can possibly write with the tools. For some platforms, like the original C compiler, it’s three lines of text and a single command-line invocation to get to something useful and executable-as platforms grow more complicated, the number of steps required to get something built can be more complicated. (Java developers probably still shudder at the memory of how many steps were required to get "Hello, EJB!" going.) Flex still sits somewhere near the simple end of that scale, but it does require more than just a single text file to show things off.
Scaffolding
The relationship of Flex to Flash is very much like that of Java to the JVM-Flex is a tool (an entire SDK, if we must be entirely accurate) designed to generate the bytecode and assemble the resources into a single bundle, the .SWF file, suitable for execution on the Flash platform. As such, Flash requires some kind of execution engine or virtual machine to execute SWF files. Generally, that engine/VM is already present on the user’s machine when the SWF file is encountered, but not always; as a result, either the user must take care to ensure the Flash platform is already pre-installed, or the developer will have to take care to enable "just-in-time" installation of the platform when the user first sees it.
Practically speaking, that previous paragraph boils down to this: for Web applications, a SWF file requires some kind of small HTML scaffolding around it to "bootstrap" the Flash VM into place, much like a Java applet required similar kinds of scaffolding to get the JVM up and running. Back then, using applets, it meant telling the browser "an applet goes here", then pointing at the correct JAR file and firing up the right class. The HTML scaffolding for flash is remarkably similar, as seen in Listing 2-1, telling the browser "a Flash thing goes here", then pointing at the SWF to load and giving it some details about the environment around it.
Listing 2-1
<html> <body> <object classid="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000" codebase="http://active.macromedia.com/flash2/cabs/swflash.cab#version=4,0,0,0" width="1024" height="768"> <param name="movie" value="MyFirstFlex4App.swf" /> <embed src="MyFirstFlex4App.swf" width="1024" height="768" pluginspage="http://www.macromedia.com/shockwave/download/index.cgi?P1_Prod_Version=ShockwaveFlash" /> </object></body>
</html>
Most of the HTML scaffolding is essentially ignorable for now-the key element is buried in the center of the file, inside the <EMBED> child tag beneath the <OBJECT> tag. The "src" attribute describes, not surprisingly, the name of the SWF file to be executed when this page is loaded and displayed inside of the browser. The <PARAM> tag describes the URL at which to find this file; since we’re working off of the local filesystem for now, this will be a direct duplicate of the "src" attribute in <OBJECT>. The "width" and "height" attributes are pretty self-explanatory. All of this is described in glowing detail on the Adobe website, see this link and this link, for those who want to understand the purpose of all the tags and possible parameters. (For the briefly curious, <OBJECT> is for IE 3.0, and <EMBED> for Netscape Navigator 2.0. Yeah, Flash goes back that far.)
Those who are curious can, if they wish, fire up the page in the browser, just to see what we get. It’s not particularly exciting, but it will serve as a quick test to see if the Flash bits are already on the machine. It sort of goes without saying, but if they’re not, now’s a good time to pull them down.
64-bit? Madness, I say! Madness!
One quick note about the Flash player and 64-bit browsers: they don’t go together. Specifically, 64-bit browser support for Flash is missing, so attempts to fire up Flash in a 64-bit browser will fail spectacularly. Adobe’s response is "just use the 32-bit version of the browser, everybody else does", and "64-bit support is coming", as seen here.
Markup and Code
Much like HTML has become, Flex is a two-pronged tool. On the one prong, developers lay out the user interface components in a markup language (XML in Flex) that describes the various buttons, controls, and what-not involved in the application. Creating a static-text "hello, world" would be a simple exercise in markup. Unfortunately, that doesn’t show off the other half of Flex, which is the code written to respond to the various events that controls can fire, and in which the developer will be doing the actual "work" of the application. So we’ll complicate things just a touch and create a button on the page, for which we’ll write an event handler to pop up a message box saying "Hello world", instead.
Flex’s compiler, mxmlc, expects markup to reside in a text file with extension "mxml", so fire up the trusty text editor and create "MyFirstFlex4App.mxml". (Ideally, use an editor that understands XML syntax, so as to help avoid the obvious XML errors like forgetting closing tags and such.) In it, drop the text shown in Listing 2-2. As with most "Hello" examples, the goal here isn’t to understand all of the nuances, but to get a general feeling for the language and environment as a whole, and sanity-check that the tools and runtime are all working correctly.
Listing 2-2
<?xml version="1.0" encoding="utf-8"?> <s:Application xmlns:fx="http://ns.adobe.com/mxml/2009" xmlns:s="library://ns.adobe.com/flex/spark" xmlns:mx="library://ns.adobe.com/flex/halo" minWidth="1024" minHeight="768"> <s:Button x="17" y="14" label="Button" id="btnSayHello" /> </s:Application>
MXML files are, at heart, well-formed XML files, which means the XML namespaces serve the same purpose as any XML namespace does, that of keeping different tag names lexically scoped. Think of them as serving the same role as Java packages. In truth, looking at the code, only two of those namespace prefixes are ever used in this example, fx: (which we’ll use in about 4 paragraphs) and s:, but this set of namespace prefixes tend to appear in lots of Flex programs, and declaring extra namespaces has zero effect on the resulting program (just like importing unused Java packages), so it’s probably a good habit to get used to having them, at least for now.
The rest of the markup, then, is rather pedestrian: the "s:Application" tag describes that this is an application, and it contains a single child control, the "s:Button". The attributes to each are deliberately designed to be instantly familiar to anyone who’s ever created an HTML form. We haven’t described what this Button will do when clicked, but in the spirit of "release early, release often", let’s give what we’ve got here a spin and see what emerges.
But it doesn’t work on my system!
If nothing appears, or for some reason your browser starts pulling bits down from Adobe, don’t panic; the HTML scaffolding is trying to minimize the work on the users’ part by pulling down the latest Flash player from the Adobe site. It’s a sign that the Flash player wasn’t on your box already, and after a few minutes and the usual "Are you sure?" dialog boxes, Flash should be ready to go.
In the event that it seems more serious than that, point your browser at << Adobe URL >> to verify that Flash is, in fact, installed on your box correctly. If that fails, you may need to have a long chat with your machine’s system administrator to figure out what’s causing the failure, which, unfortunately, is beyond the scope of this article.
Building
Building a Flex app consists of compiling the .mxml files into .SWF files, using the mxmlc tool. Executing the tool ("mxmlc MyFirstFlex4App.mxml"), assuming mxmlc is on the PATH and the .mxml file is in the same directory, does what all command-line compilers have done since Time began: it offers up some description of what it’s doing, and assuming the input code is correct, produces the .SWF file into the same directory when finished. This means that if we then open the scaffolding HTML file in the browser, something like Figure 2-3 should be looking back at you when the Flash plugin finishes loading. It’s still not particularly exciting, since nothing happens when users (you, me, or your Aunt Sally, if she happens to be looking over your shoulder) click on the button.
Figure 2-3
Code
Aunt Sally turned out to be too fast for you-she clicked the button, and nothing happened, and she was disappointed. Fixing that particular problem lies in defining an event handler for the button’s "onClick" event, again just like what a developer would write for an HTML form. And, again in what seems to be a deliberate parallel to Web development, the language used to write that event handler is a language deliberately similar to JavaScript, called ActionScript, also known as AS to its close friends and family.
For simple demos, it’s generally easiest to include the AS directly inside the markup file, so drop back into the .mxml file and drop the text found in Listing 2-4 into the middle of it. Two changes appear here: the child "<fx:Script>" tag in which the event-handler function is defined, and the addition of the "click" attribute to the Button declaration naming the function to execute when the user clicks it. For those unfamiliar with the "CDATA" section, it’s an XML-ish way to essentially tell the XML parser to stop treating "<" and other tag tokens as tag tokens; this turns out to be critical when writing code inside a markup file, particularly when working the with comparison and boolean operators ("<" and "&"), since they’d need to be XML-escaped otherwise. (I’m sorry, folks, but "if (1 < 5)" and "if (x &&l y)" just doesn’t really read nicely.)
Listing 2-4:
<?xml version="1.0" encoding="utf-8"?>
<s:Application xmlns:fx="http://ns.adobe.com/mxml/2009"
xmlns:s="library://ns.adobe.com/flex/spark"
xmlns:mx="library://ns.adobe.com/flex/halo"
minWidth="1024" minHeight="768">
<fx:Script>
<![CDATA[
import mx.controls.Alert;
protected function btnSayHello_clickHandler(event:MouseEvent):void
{
Alert.show("Hello World");
}
]]>
</fx:Script>
<s:Button x="17" y="14" label="Button" id="btnSayHello"
click="btnSayHello_clickHandler(event)"/>
</s:Application>
Long-time JavaScript authors will immediately note a few differences between stock JavaScript and ActionScript; Adobe has chosen to break away from traditional JavaScript in an attempt to close off some of the popular criticisms of that language. ActionScript is more strongly typed than JavaScript, for example, so declarations in AS will require a "type descriptor" to help the compiler ensure that everything’s being used appropriately. ActionScript also requires a reference to other packages (libraries) in order to use them; hence the "import" statement at the top of the Script block.
Like JavaScript, however, the name of the function is purely convention-if "control_handler" doesn’t meet your particular coding conventions, and you prefer something like "foo", go for it. (Just don’t complain later.)
Recompile the code to produce a new .SWF that now responds to button-clicks, reload the "hello.html" page in the browser, and lo and behold, clicking on the button produces Figure 2-5. Ancient ancestors, accept our homage.
/filters:no_upscale()/articles/java-developer-guide-flex/en/resources/figure 1 1.jpg){kind=link}
/filters:no_upscale()/articles/java-developer-guide-flex/en/resources/figure 1 3.jpg){kind=link}
/filters:no_upscale()/articles/java-developer-guide-flex/en/resources/figure 2 3.jpg){kind=link}
/filters:no_upscale()/articles/java-developer-guide-flex/en/resources/figure 2 5.jpg){kind=link}
Figure 2-5
Rinse, then Repeat
Java developers who’ve spent more than five minutes writing Java code already know the benefits of the Ant build tool-anything repetitive is just ripe for human mistake, and all the loss of productivity and momentum that goes along with that. (If you’ve never lost any time whatsoever trying to debug something only to discover that code you thought you’d compiled wasn’t actually compiled, please feel free to move on to the next article in the series.) Given that Flex is a compiled environment just as Java is, it would make sense that Flex has a tool similar in stature and direction as Ant, but Adobe’s gone one better: rather than go off and reinvent the wheel, Flex includes a series of Ant tasks to make it easy for the Java/Flex developer to just plug Flex into their build script.
(Yes, this means you need to have Ant installed. If you don’t have Ant installed already-either as part of your IDE or the straight command-line install from this link –then please turn in your Java developer card, go back to your COBOL, and we’ll pretend nobody saw anything. If you use Maven, you’re on your own-Adobe doesn’t support it "out of the box", though there are several tutorials for installing the Flex SDK bits into a Maven repo. But honestly, if you use Maven... seek help. Immediately.)
Planning
We have two source files, the "real" Flex layout and code, MyFirstFlex4App.mxml, and the scaffolding HTML file designed to display the compiled Flash application, hello.html. Typically, Java convention suggests that all source files should be inside a "src" directory off the project’s root, so if you’ve not already done so, create said subdirectory and drop both files in there. Just as a sort of test, to make sure that everything still works, kick off an mxmlc build to build the .SWF file from the "src" directory, generating the output file back to that directory, using "mxmlc src/MyFirstFlex4App.mxml". Of course, traditional convention also demands that build artifacts show up in a different directory from the source directory (to make it easier to clean up the generated built artifacts, if nothing else), and mxmlc supports that, via the "output" command-line argument: "mxmlc src/MyFirstFlex4App.mxml –output dist/MyFirstFlex4App.swf".
Assuming all that works, we have then the basic layout for an Ant build file that does all of these things for us. The Flex build tasks will make it easier, but let’s stick with incremental progress for now. The first-pass Ant file, using straight <exec> tasks, looks like Listing 3-1.
Listing 3-1:
<project name="MyFirstFlex4App" basedir="." default="compile"><target name="init">
<mkdir dir="build" />
<mkdir dir="dist" />
</target><target name="compile" depends="init">
<exec executable="mxmlc">
<arg value="src/MyFirstFlex4App.mxml" />
<arg value="-output" />
<arg value="dist/MyFirstFlex4App.swf" />
</exec>
</target><target name="clean">
<delete dir="build" />
<delete dir="dist" />
</target>
</project>
Flex Tasks
Of course, the biggest drawback to using the <exec> tag is that we have to lay out each and every parameter in a separate <arg> tag, and that will get somewhat tedious over time. Plus we lack any sort of validation that the Ant tasks might do, so clearly there’s some value-add in switching over to use the Adobe-supplied Ant tasks. Doing so is as easy as adding an Ant <taskdef> to include the Flex tasks, then switching over to using the Flex-supplied task elements to do the compilation.
First, however, a caveat: as described in the README in the Flex SDK’s "ant" directory, the Flex Ant tasks require that the Flex tools be on the PATH in order to execute properly. Since we’ve been building from the command line all along, this shouldn’t be a problem for now, but if you close the Terminal window you’ve been using and run into problems later, check to make sure that’s the case.
Switching over to use the <mxmlc> task is as easy as flipping from <exec> to <mxmlc> and providing the same command-line parameters as attributes to the task tag, as shown in Listing 3-2. Notice that the FlexTask version is going to be shorter, since the compiler parameters are now captured as attributes and not explicit <arg> tags.
Listing 3-2:
<target name="compile" depends="init"> <mxmlc file="src/MyFirstFlex4App.mxml" output="build/MyFirstFlex4App.swf" /> </target>
Ant scaffolding
Before we can make <mxmlc> work, however, we need to take one additional step, that of telling Ant where to find the Flex tasks. This is the job of the Ant <taskdef> tag, which requires a reference to the "flexTasks.jar" file in which the Ant tasks themselves are defined, and a reference to the "flexTasks.tasks" file which maps the tag names ("mxmlc") to the Java class for that task ("flex.ant.MxmlcTask") defined in the JAR file. Assuming, then, that Flex is installed on my system at C:\Prg\flex4.5, the <taskdef> would read something like "<taskdef resource="flexTasks.tasks" classpath="C:/Prg/flex4.5/ant/lib/flexTasks.jar" />". Of course, Flex is not likely to be installed on your computer at the same location (particularly if you’re using a Mac or Linux box), which means that if we’re both working on the same project, somebody’s going to get frustrated particularly quickly: your "/usr/local/flex-4.5" is not going to match my "C:\Prg\flex-4.5", and if the Ant script embeds the Flex SDK installation directly into the script, we’re going to need a "two men enter/one man exits" kind of discussion to fix it.
This is where Ant’s use of property files provides salvation: define a local text file, not under source control, called "local.properties", and in it define a single name=value pair, "FLEX_HOME=<wherever you installed it>". Then, the taskdef becomes "<taskdef resource="flexTasks.tasks" classpath="${FLEX_HOME}/ant/lib/flexTasks.jar" />", and we can both be happy.
Next step, then, is to simply flip over to using <mxmlc>, as shown in Listing 3-3.
Listing 3-3:
<project name="MyFirstFlex4App" basedir="." default="compile"><property file="local.properties" />
<taskdef resource="flexTasks.tasks"
classpath="${FLEX_HOME}/ant/lib/flexTasks.jar" /><target name="init">
<mkdir dir="build" />
<mkdir dir="dist" />
</target><target name="compile" depends="init">
<mxmlc file="src/MyFirstFlex4App.mxml" output="build/MyFirstFlex4App.swf"
compiler.debug="true" />
</target><target name="clean">
<delete dir="build" />
<delete dir="dist" />
</target>
</project>
Yes, it’s boring Ant stuff, but a little attention to infrastructure now will pay off later. Once set up, this basic Ant script can become a starting project template for all your future Flex projects, just as that basic Ant Java/web-app script did back when servlets were new.
By the way, it may strike the curious reader to wonder what the full list of compiler command-line parameters are; discovering this is as easy as typing "mxmlc –help list" to get the full list of parameters, and by doing so we obtain the full list of <mxmlc> attributes, as well. Adobe states, back in that README in the FlexSDK/ant directory, that compiler parameters are expressed as attributes in the Ant task. Thus, if we want to turn on the command-line parameter "-compiler.debug", we do so by adding "compiler.debug=’true’" to the <mxmlc> task.
Thus, things are good. More or less.
Wrappers
The problem, of course, is that the "hello.html" scaffolding file is still residing inside of "src", and to have a complete "build" we really need it to be sitting next to the .SWF file (or the other way around, if you prefer). While we could go ahead and just do a <copy> of the file from "src" to "dist" (doing the same for the .SWF if we built it into "build", another common Ant convention), there’s actually a better way.
One of the FlexTasks tasks is the <html-wrapper> task, which does precisely as its name implies: generate the HTML scaffolding file. In fact, it generates a very rich scaffolding file, complete with JavaScript to auto-detect browser capabilities, and more. While it’s well beyond the scope of this article to describe everything the generated index.html and swfObject.js code does, suffice it to say that it’s well beyond the simple scaffolding I originally presented in "hello.html", and therefore the far better choice. Particularly when we can generate it with a snap of the fingers via Ant, as shown in Listing 3-4.
Listing 3-4:
<project name="MyFirstFlex4App" basedir="." default="compile">
<property file="local.properties" />
<taskdef resource="flexTasks.tasks"
classpath="${FLEX_HOME}/ant/lib/flexTasks.jar" />
<target name="init">
<mkdir dir="build" />
<mkdir dir="dist" />
</target>
<target name="compile" depends="init">
<mxmlc file="src/MyFirstFlex4App.mxml" output="build/MyFirstFlex4App.swf"
compiler.debug="true" />
</target>
<target name="dist" depends="compile">
<copy file="build/MyFirstFlex4App.swf" todir="dist" />
<html-wrapper title="Hello, Flex" height="640" width="480"
swf="MyFirstFlex4App" output="dist" />
</target>
<target name="clean">
<delete dir="build" />
<delete dir="dist" />
</target>
</project>
Summary
There is yet a long way to go, grasshopper, before we can snatch the pebble from the palm: we have two sets of UI components to discuss, input events, remote communications, libraries, a whole language (ActionScript), and that’s all before we get into fun topics like animation and gaming (my personal favorite) and mobile devices (a subject of some controversy). Fortunately, I have a lot of time to write, and Adobe has a lot of room left in their budget to have me do so, so this is just the first of many, albeit shorter, articles to come, as we walk through Flex and Flash from the Java developer’s perspective. In time, we will come to see everything that Flex and Flash has to offer.
But that, as they say, is a story for another time.
About the Author
Ted Neward is a Java and .NET developer, consultant and author who finds himself growing steadily more interested in making pixels change colors. He resides in the Pacific Northwest.