Posts in Category "Flex 3"

Master-Detail Flex Application

I’m an Adobe writer assigned primarily to Flex Builder and the Flex SDK. I joined Adobe in October of 2007 and have spent the first few months learning and using Flex and Flex Builder.

I’ve recently completed my first Flex application, and am using this blog to write about my learning experience, and also to describe some of the concepts behind the application that make it work. Actually, these are two applications that work together, vRadio and RadioLoginDB.

These applications illustrate how to use Flex to create a master-detail application that accesses data from a PHP server, and also incorporates PHP sessions.

At the end of this posting is a list of documentation sources I used to learn how to create the applications. I also have links to the source files.

vRadio and RadioLoginDB applications

I have always been a fan of Community Radio, and in the past I’ve Googled “Community Radio” to find new stations to listen to over the web. I created the vRadio application to provide a Flex alternative that lists Community and Talk radio stations, providing details about each station including station name and location, station graphic, and clickable links to open the station. RadioLoginDB is a CRUD application to update the database of radio stations used by vRadio.

vRadio is a Master-Detail application, and corresponds to many type of applications that present stored data in a variety of presentation formats, and also provide forms for updating the data.

What is interesting about the the vRadio application is the way Flex handles XML data using the E4X format. By providing an XML feed into the vRadio application, the application displays the XML data in a tree view. When the user clicks a node in the tree, details are displayed.

Continue reading…

Adding Java Development Tools to Flex Builder Standalone

Many Flex, Adobe AIR, Adobe BlazeDS, and Adobe LiveCycle ES developers choose to use the Eclipse plug-in configuration of Flex Builder so that they can develop Java code in the same IDE that they use to develop the MXML and ActionScript code. While the standalone version of Flex Builder does not contain tools to edit Java code by default, you can install them as Eclipse plugins. That lets you use the standalone version of Flex Builder to edit Java code.

To install the Java development tools in the standalone version of Flex Builder:

1. Use the Help > Software Updates > Find and Install menu command to open the Install/Update dialog box

2. Select Search for new features to install.

3. Click Next.

4. In the results, choose Europa Discovery Site.

5. Click Finish.

6. Select the Java Development package to install.

7. Click Next.

8. Accept the license.

9. Click Finish.

Note: You might be prompted to install additional plugins required by the Java Development package.

To change perspective:

1. Use the Window > Perspective > Other to access all perspectives.

You can also click the Open Perspective button in the upper-right corner of the workbench window, then select a perspective from the pop-up menu.

2. Select Java from the list of perspectives.


Stephen Gilson
Flex Doc Team

Creating ASDocs for Custom Adobe AIR Components

The Flex ASDoc tool parses one or more ActionScript class definitions to generate API reference documentation for all public and protected methods and properties, and for all [Bindable], [DefaultProperty], [Event], [Style], and [Effect] metadata tags. By default, the ASDoc tool links in all of the Flex SWC files required to compile custom Flex components. However, to use ASDoc to generate documentation for custom Adobe AIR components, you must link in the necessary AIR SWC files.

For example, you create a custom component named MyAirComboBox that extends the AIR mx.controls.FileSystemComboBox component. The directory location of your custom component file is:


Use the following ASDoc command to generate API reference documentation for MyAirComboBox:

..\bin\asdoc -doc-sources C:\myApplication\myComponents\ -library-path+=..\frameworks\libs\air -main-title "My AIR API Documentation" -window-title "My AIR API Documentation" -output air-asdoc

This command assumes the following:

  • You run the command from the directory C:\Program Files\Adobe\Flex Builder 3\sdks\3.0.0\asdoc in your Flex Builder installation directory structure. If you are using the Flex SDK, or have installed Flex Builder on another operating system, modify the paths in this command as necessary.
  • The AIR SWC files are installed in the directory C:\Program Files\Adobe\Flex Builder 3\sdks\3.0.0\frameworks\libs\air. This is the default directory location for a Flex Builder installation.This command uses the library-path option to the ASDoc tool to specify the directory location of the AIR SWC files. The”+=” operator to the -library-path option specifies to append the AIR SWC files to the Flex SWC files.
  • The ASDoc tool writes the output to the directory C:\Program Files\Adobe\Flex Builder 3\sdks\3.0.0\asdoc\air-asdoc.

If you have created multiple AIR components, you can use the following ASDoc command to generate documentation for an entire package:

..\bin\asdoc -doc-sources C:\myApplication\myComponents -library-path+=..\frameworks\libs\air -main-title "My AIR API Documentation" -window-title "My AIR API Documentation" -output air-asdoc

See the Flex 3 documentation for more information on the ASDoc tool.


Stephen Gilson
Flex Doc Team

Migrating applications from Flex 2 to Flex 3

Migrating from Flex 1.x to Flex 2 was — how can I put it — painful. We scrubbed the APIs to make them consistent; as a result, many properties, methods, events, and even some constants changed, and sometimes changed again. We added and removed classes and interfaces. Heck, we even changed the capitalization of “Void” to “void”. In addition, the underlying language went from ActionScript 2.0 to ActionScript 3.0. There was no shortage of tasks for updating apps from 1.x to 2.

This time around, however, the APIs have already been through the scrubbing and many of the issues have been ironed out. Most of the migration duties you’ll encounter will be related to updated features, like:

Localization — The l10n system has changed alot (for the better!). It’s now much simpler to implement, and it supports runtime locale-switching. You can use the same properties files, but you might have to rewrite the way they are accessed. Check out the localization doc.

Style properties — A number of style properties have changed to support the new subcomponent style feature.

Deep linking — This is a new feature, but if you were using the HistoryManager class, you really should switch to using the BrowserManager class to do all your browser/Flex app communication.

Compiler and configuration args — A few compiler arguments have changed. If you use config file or ant tasks to do your compilation, you might have to modify your files.

Here are some resources that should help with migration issues:

  • Deprecated elements in the Language Reference — A list of all the class elements that are now deprecated. The compiler will also warn you about these when you try to compile, but you can get a sense of what has changed from this list.
  • Backwards compatibility — This includes a list of differences between the configuration files for SDK 2.0.1 and SDK 3, as well as a list of the changes to the framework.
  • Understanding Flex 3 Migration Issues on Joan Lafferty’s blog: Part 1 and Part 2

It’s also important to realize that with Flex Builder 3, you can compile your apps against the new compiler (version 3), or against any version of the compiler that you have installed. This way, if your code does not use any of the new features and you don’t want to migrate yet, but you want to use Flex Builder 3, then you can without any issues. Of course, there’s doc on that, too.

Flex 3 (and Flex 3 Documentation) is Live!

We started shipping Flex 3 today. Wow! This has been quite a release and, although you’re probably reading this on all the Adobe blogs, we think it’s pretty special. I know that we’ve made a number of improvements to the docs, and am going to ask the writers to create their own posts to enumerate their personal favorites. For my part, I’ll call out two:

  • The Flex 3 Getting Started Experience – With Flex 2 and 2.0.1, we had a lot of negative feedback from Flex newbies.My manager, in her infinite wisdom, gave us a lot of support in hiring Inquirium (an instructional design firm) to interview Flex developers, figure out their common patterns/problems, and create a new getting started roadmap. Some hurdles we knew about (understanding that Flex access data indirectly through a server), but others were a surprise (a lot of people got caught up with asynchronous events). We then hired Trilemetry (big thanks to Emily, Annette, and Bob) to “realize” the Getting Started Experience. This turned out to be bigger than we thought, but I think it works really well, and the Beta feedback has been extremely positive.
  • Revised table of contents (TOC) architecture for Flex Builder online Help and LiveDocs – In our work with Inquirium, it became clear that viewers weren’t thinking about “books” in the online doc experience. The revised TOC feels more navigable and I think it makes it easier to find stuff. Please check it out and let me know what you think. Note that we only did this for the core Flex books, so Flex Builder, Data Visualization, AIR, and ActionScript are still presented as books. Also note that material is still available as books through the Flex Help Resource Center.

OK. I lied. Two more things:

  • Obviously, I’m focusing on Flex, but AIR went live today, too, and this is a significant milestone for Adobe. For Flex developers, it’s pretty simple: Any app you write for the browser should just run in the AIR runtime (and the Flex 3 LiveDocs include Developing AIR Applications with Flex). You can also take advantage of the extended functionality inherent in a desktop application and I recommend scanning the discussions of windows, menus, taskbars, files, data, HTML content and Rich media content. In particular, I think the drag & drop and local SQL database discussions are cool.
  • Please use the public bugbase to report problems with the Flex 3 documentation. You can also search the bugbase to see if anyone else has already reported an issue.

Thanks everybody for your feedback during the Flex 3 Beta cycle. You made a difference.

On to Flex 4!

Measuring Message Processing Performance in BlazeDS

One place to examine application performance is in the message processing part of the application. To help you gather this performance information in BlazeDS, you can enable the gathering of message timing and sizing data.

When enabled, information regarding message size, server processing time, and network travel time is available to the client that pushed a message to the server, to a client that received a pushed message from the server, or to a client that received an acknowledge message from the server in response a pushed message. A subset of this information is also available for access on the server.

Download the new chapter’s PDF: Measuring Message Processing Performance

Java-based Compiler API

Flex 3 includes a Java-based compiler API that lets you compile SWF and SWC files from Java applications. The API supports all the same options as the mxmlc and compc command-line tools. The API includes classes like Application, Logger, and Project.


The API’s JavaDocs are here: (245K)

There is a PDF which describes usage here: Compiler API Guide (194K)

BlazeDS Beta 1 Documentation

Adobe has made a very exciting announcement. We announced a new open source data services project called BlazeDS. BlazeDS Beta 1 is now available on Adobe Labs.

BlazeDS contains the latest versions of the Message Service, Remoting Service, and Proxy Service that were previously only available as part of Adobe® LiveCycle® Data Services ES. BlazeDS is a server-based Java remoting and messaging technology that lets developers easily connect to back-end distributed data and push data in real time to Adobe Flex™ and Adobe AIR™ applications.

BlazeDS usage documentation is available in HTML format on LiveDocs and as a PDF file:

BlazeDS ActionScript and Java reference documentation is available in these ZIP files:

Information about setting up a BlazeDS project in Flex Builder 3 is available here:

Key features and benefits of BlazeDS are highlighted in the release notes. A great way to get started quickly with BlazeDS is the Test Drive application. The Test Drive is one of the sample applications included in the BlazeDS installation.

Are you using the Flex 3 Getting Started Experience?

For Beta 2, we introduced the online Flex 3 Getting Started Experience, found at This site is also available from the Flex Builder 3 Start Page.

We think that this site is a big improvement over the Flex 2 Getting Started manual and I encourage you to check it out. However, we’re seeing something puzzling, and would like your feedback.

We are seeing very few comments (about 2 per week) and are trying to figure out why. If any of you have tried to add a comment to a page on the Flex 3 Getting Started Experience and given up/failed for any reason, can you please respond to this post?

Conditional compilation in Moxie

Moxie includes conditional compilation support. Conditional compilation lets you include or exclude blocks of code when you compile. It is generally used for debugging or instrumentation where there might be large blocks of code, classes, or entire libraries that you want to use during development but then want to exclude from your release version of the application.

The documentation did not get into the release of Beta 2, so here is the PDF that describes how to use this feature:

Download file (40K, PDF)