Flex the interface

Crashing onto the user interface development scene over the last year has been some surprising technology from <a href="http://www.adobe.com/">Adobe </a> called <a href="http://www.adobe.com/products/flex/">Flex</a> .&nbsp; Although it&#39;s been out in the wild since 2004, it wasn&#39;t until <a href="http://en.wikipedia.org/wiki/Adobe_Flex">v3.0 was released in Feb 2008</a> that we really started to hear about Flex.&nbsp; Especially with the announcement and pre-release of <a ...

InformationWeek Staff, Contributor

September 17, 2008

8 Min Read

Crashing onto the user interface development scene over the last year has been some surprising technology from Adobe called Flex .  Although it's been out in the wild since 2004, it wasn't until v3.0 was released in Feb 2008 that we really started to hear about Flex.  Especially with the announcement and pre-release of Microsoft Silverlight , the idea of building applications on a runtime inside the browser has gained serious traction.  I'll go over aspects of Flex and why I think it's the future of application development.

Most people, when asked about Adobe, think of the ubiquitous Acrobat Reader for PDF files, or possibly the myriad of design tools that Adobe has marketed for years.  However, their biggest impact beyond PDF has likely been Flash - that runtime that hosts those glitzy animations you see sprinkled all over the web now.  Corporate websites are particularly heavy users of Flash as a way to make a big impact on prospective clients.  

Flash made its inroads quietly and without fanfare over the course of several years as more and more web designers and marketing groups created Flash files and prompted users to download the Flash runtime - which thankfully was small enough in size that very few people objected to doing so.  So many people in fact, that Flash claims to have a 98% penetration rate across all browsers - that's platforms also.  Even Java hasn't achieved such a density of users most of whom have no idea of what Flash is other than someone needed it for a fancy animation.

However, for those of you unfamilar with Flash, think of it as the equivalent to the Java runtime (JRE).  Essentially, a Flash file (SWF) pronounced "swiff", is a bytecode file that is loaded and interpreted by the Flash runtime.  This allows a single Flash file to run on multiple platforms - Mac, Windows, etc - without change.  To me, this is what Java tried to be back in the mid-1990's, but it was Flash that achieved it.  So the trick is to create a Flash file in a tool, then save that file as a SWF and then run it.

For graphic designers, comfortable with rich design programs, and a creative flair, the idea of storyboarding a set of scenes, linking them together with transition animation, and possibly user input (keyboard/mouse) is straightforward.  Their tools are built around this model.  However, what do you do if you are a software developer more comfortable with traditional programming languages, procedural logic, a tiered model, etc?

The answer is Flex.

Rather than come up with a new product that provided an alternative to other traditional development environments like Java, .NET, etc, Adobe did a really, really smart thing - they said, "Hey, we already have a runtime, it's Flash.  What if we created a way for developers to create applications that compiled down to a Flash file and then run it on the Flash runtime?".  And that's what they did with the birth of Flex.

At a high level, you could think of the relationship between Flash and Flex as the same between the Java runtime (JRE) and the Java language.  Essentially, Flex is a name for a set of development technologies that can be compiled down to run on the Flash runtime.  Within these technologies are some key actors, and I'll go over them now.


MXML is an XML-based, user interface description language although the word MXML has no specific meaning as an acronym.  Within MXML, you specify declaratively what you want done rather than exactly how it should be done.  A Flex application has as its top-level item a mx:Application tag where mx refers to a Flex namespace.  Within the Application tag, you begin specifying containers such as mx:Panel (for windows with titles), mx:VBox (vertical layout), mx:HBox (horizontal layout), and so on.  Within one of these containers, you may specify additional nested containers (to many levels) and/or other "widgets" such as Text boxes, Combo boxes, etc.  To boil this down, MXML is how you specify your user-interface - you may have many MXML files which are pieces (components) of your overall application.  All of these MXML files are converted into a language called ActionScript, and then down to the Flash bytecode by the Flex compiler.


The ActionScript language (now at version 3) is a derivative of the European Computer Manufacturers Association (ECMA) scripting language called ECMAScript .  This standardized language is also the basis for Microsoft's JScript and other dialects of modern Javascript.  So the upshot is that if you know Javascript, you pretty much know ActionScript.  

With the Flex world, ActionScript is the "language" of Flex.  It's the way you specify how you want your Flex app to behave.  Oftentimes you can write most of the specification of the UI in MXML and then sprinkle the MXML with a bit of ActionScript to handle events, special logic, etc very much like you'd do in an HTML page.  However, you can also go beyond this and create ActionScript classes which are very much like classes in Java, C#, etc.  These entities are typically defined in files with a ".as" extension (for ActionScript) and compiled along with the rest of the Flex app.  ActionScript classes can be used in an MXML file just as though they were built-in MXML tags which allows you to create whole suites of building blocks for applications.


Of course, to build a Flex app you need a compiler at the very least.  It would also be nice to have a modern IDE that provides code-assist, drag-drop, UI designers, and so on.  To the rescue comes Adobe FlexBuilder3 which is a commercial application based on the Eclipse IDE.  If you know Eclipse (or MyEclipse ), you'll be right at home in FlexBuilder.  For those of you using Eclipse for your J2EE projects, you can install a FlexBuilder plug-in to Eclipse that allows you to treat Flex projects as just a perspective in the IDE.  So you can code, compile and debug both the client side Flex application and the server-side J2EE code which brings me to Blaze.


This is one of those really cool plumbing technologies that can make a Flex app rock.  Blaze is the name for a set of Java technologies packaged as .jars (think .war) and deposited on the J2EE app server of your choice.  If you don't care, and just want to get started quickly, Adobe has available a complete install of Apache Tomcat including an instance of Blaze.  Just pull it down, extract and you're ready to go.  

But just what is Blaze?  It's a technology that provides up to a 10x performance increase in transmitted data over HTTP.  On the client (Flex) side, you make calls to the server using a special mx:RemoteObject tag specifying the name of the object you want to call on the other side - object as in POJO.  Now that's cool.  No need to write servlets, routing code, etc to get to the bits that do the work.  Just write some normal POJO's on the server, and call them from the client via Flex/Blaze.  To accomplish this feat, Adobe created a new messaging protocol called Adobe Message Format (AMF ) which was released as open-source.  This efficient, binary format allows developers to send greater quantites of data down the pipe without killing performance.  To tell Blaze about where your POJO's are located, a simple set of additions to a Blaze XML file on the server is needed indicating the full class name of the POJO and the name by which it's known on the client-side.  You can return native types, Java objects, and exceptions.  Java objects are converted by Flex into either 1) dynamic objects where you need to know the names and methods of the returned object, or 2) an ActionScript object that maps to the POJO.  In the latter case, you can generate or write your own mapping ActionScript objects if you have special requirements.


Of course, since Flex uses Flash as the runtime, any Flash artifacts you may have can be re-used as-is.  If you have a Flash designer on staff, they can create pieces in Flash that you can re-use quickly and easily.  And a nice touch is that Flex supports the History feature of the browser which allows you, if desired, to intercept the Back button click and interpret that as moving back a Flash/Flex panel, or some other step.


No, not the stuff we breathe.  AIR is the name of a technology from Adobe that allows Flash/Flex applications to run on the desktop client without the browser.  In essence, your nice little Flex app can run on the desktop as a full-blown desktop application - with no changes.

This just scratches the surface of the Flex world.  With Adobe releasing Flex (but not FlexBuilder) to the open-source community, the Flex team is busy working on the feature set of Flex 4 which will include enhanced support for skinning applications among many others.  

If you're a student at a university, you can get a free copy of Adobe FlexBuilder3 by emailing them a copy of your student ID or a recent invoice.  Otherwise, you can download a free trial from Adobe.

 If you're considering creating a RIA application, or just want to embed some nifty animation in your Web app, but don't feel comfortable with Flash itself, give Flex a try.  You're going to hear a lot more about this technology in the coming months and years.


Never Miss a Beat: Get a snapshot of the issues affecting the IT industry straight to your inbox.

You May Also Like

More Insights