Adobe Flash Catalyst: Under the Hood - Part 5 The Transport
In the 5th and final part of this continuing series, guest authors James Polanco and
Aaron Pedersen show how the integration of Flash Catalyst and Flash Builder is aided by a common file format.
James Polanco and Aaron Pedersen are the guiding geniuses behind the Web development firm developmentarc.com, based in San Francisco. James and Aaron are working on a book for Adobe Press on integrating Adobe Flash Catalyst and Flash Builder 4 (both just released as public betas) into the Web designer/developer workflow. Throughout June, they've been posting a weekly series of items that takes a peek "under the hood" of these innovative tools.
Adobe Flash Catalyst: Under the Hood—Part 5 The Transport
By James Polanco and Aaron Pedersen
One of the main advantages of Flash Catalyst is its workflow integration with Flash Builder. Designers can start with a static design; add interactive features in Flash Catalyst; and then hand off their creation to developers for a direct import into Flash Builder. To make this possible Adobe has created a new file format called
FXP. The format allows for Flash Catalyst projects to be created and consumed by Flash Builder via the commonly supported
FXP extension. However, this file format is not as new as it seems and those familiar to Flex development will recognize it right away.
Before we crack open the
FXP format and expose its true form, we need to first understand what Flash Catalyst is built on top of. To users familiar with Adobe Creative Suite applications and tools such as Illustrator, you will feel right at home with Catalyst. You’ll find a Layers panel, many of the same vector design tools, and even an animation timeline that will be familiar to Flash Professional, After Effects and Premiere users. However Catalyst is not built on the same engine as the Creative Suite products. Flash Catalyst actually shares the same engine as Flash Builder, which is built on top of Eclipse 3.4. Eclipse is an open source IDE (Integrated Development Environment) platform that is normally associated with hard-core developer tools that produce Java, Rails, and ActionScript code.
With this common platform, Flash Catalyst can leverage one of Flash Builder’s most powerful modules; the Code Model. The Code Model is what allows both tools to interpret the Flex project from a code structure standpoint and enables the tools to edit the Flex project code in real-time. For example, code hinting and code completion are examples of features that the Code Model provides to Flash Builder.
Returning to the
FXP format, if we were to open an
FXP file outside of Catalyst or Flash Builder, we discover it is nothing more than a compressed Flex project. Because of the Code Model and the Eclipse platform, Flash Catalyst can share a Flex project with Flash Builder and understand all of its inner workings. Once uncompressed the file structure of the project is almost identical to what developers have been working with since Flex Builder 2. To Flash Catalyst users it will seem familiar if you have checked out Code View and the Project Navigator panel.
Note: You can open an
FXP file by renaming the file extension from
.zip and expanding it. On the Mac, you'll have to use StuffIt Expander, as the
default compression tool provided in the Mac OS does not work for this purpose.
In the uncompressed directory you will find three top-level directories:
html-template, libs, and src.
html-templatedirectory holds all the files necessary to create the HTML page to display our Flex project within a web browser. When you run your project in either program, the
index.template.htmlwill be copied, modified based on a set of preferences, and rendered as
index.htmlin your default browser. Included in that file will be a link to all the history files produced by the history management features in Flex. Those files are located in the
For those familiar with Flex 2 or 3 projects, you will notice something new.
SWFObject.js(version 2.1) has replaced
When Flex libraries are linked to your Flex project, they are stored in your
libsdirectory. These external files are bundled as
.SWCsand contain compiled code very similar to a
.SWF. The main difference between a
SWCis that a
SWCcannot be run on its own, it must be linked into a
SWFfile at compile time. Flex libraries contain common code that can be leveraged within any Flex or Flash application. As of the public beta, Flex libraries are not available to users within Flash Catalyst, and their support in future releases is unknown at this time. There does seem to be another new file extension called
FXPLthat both products also support. In Flash Builder, a Flex Library Project can be exported as an
FXPLfile. Catalyst then has the ability (although it is not enabled in the Beta) to import the same file type. It is generally assumed that Flash Catalyst will soon be able to consume Library projects and leverage them in your Flash Catalyst projects. More than likely, at compile time the
FXPLfiles will be come
SWCs under the
All of the source files that are created when you build your user interface in Flash Catalyst are stored in the
srcdirectory. Your application will contain a file named
Main.mxml. This is the root of your application and will be the starting point of your project. Each component that you skin from your design assets will be contained in its own
MXMLfile and stored in the
src. In our screenshot above we have included two components in our application and their skins are stored here. One is a data list and the other is the item render that is leveraged by the data list. Both files are linked inside
When an FXP project is passed to Flash Builder, new files will be added as the logic of your application is constructed. Those source files will also be stored under src. Currently Flash Catalyst does not include the option to change where its files are stored, however Flash Builder allows developers to store them anywhere under src as they see fit. Because of this limitation developers should be consistent and store all skin classes created in Flash Builder under
As you can see, the file format is pretty straightforward. The most complex piece will be the
srcdirectory as your application grows. We hope that after looking inside the
FXPformat you have a better understanding of how similar Flash Catalyst and Flash Builder are to each other and how the common format helps bridge the gap between design and development.
Here are the other posts in this series:
Part 1: Introduction
Part 2: The Platform
Part 3: Design Integration Workflows
Part 4: Converting & Skinning Components