If you are a software developer, a web designer or some other sort of techie it’s very likely that you have been hearing and/or reading about Adobe Flex lately. Well, if you aren’t using it yourself but feel curious about it, or if you just want to have a notion, this extremely quick introduction is for you. Skimming through this post will not turn you into a Flex developer, but it will allow you to nod confidently and even drop some canny words the next time that Flex pops up in a conversation around the watercooler.
First things first — what Adobe Flex is not:
- It is certainly not a tool for generating lexical analysers ;¬)
- It’s not “the new version of Flash” (FKA “Macromedia Flash”). Development of Flash is on-going and the two products coexist. Flex hasn’t replaced (and won’t replace) Flash anytime soon, the reason for that being that…
- …Flex is not “an alternative to Flash”. Sorry to disappoint you, but Flex is not a way to get rid of the dependence on the Flash Player. Actually Flex is built on top of Flash and needs Flash Player to run.
- It’s not a technology to build large, native apps that need to work close to the underlying platform or which performance needs to be optimised (read below to see why I believe this).
Flex in a nutshell (a rather small nutshell):
Flex is an attempt by Adobe to make Flash attractive to, and suitable for, many software developers who were disregarding Flash as something not serious enough to use for developing “proper software”. Adobe has done a praiseworthy effort in that sense and has brought Flash to the realm of OO programming. Adobe used Eclipse to develop Flex Builder. Flex Builder alone does a lot to make old-skool software developers feel at home — it’s a proper IDE with all the features you would expect, plus the extensibility (and the slowness, I’m afraid) of Eclipse.
Flex developers use the Flex SDK (command line compilers and component class library; free as in “freedom”) and the Flex Builder (the IDE) to build their applications. Flex apps are written mainly in two languages:
- Actionscript, an ECMAScript-based language that exists since the first Flash Player.
- MXML, a loose, proprietary implementation of XML used to define GUI elements.
The output of a Flex project is one or more Flash files (.swf). In terms of the approach to the development process, the single most important change from Flash to Flex is probably removing the “movie” way of thinking. Flash animators are used to the “movie paradigm” in which the time is an essential concept. In their animations they have been working with key concepts like “timeline”, “frame” and “loop”. Flex abandons that approach.
I have found that, in general, software developers without any experience with Flash get used to Flex even faster than Flash designers who don’t know much about programming.
What Flex is good at:
- Rendering cool interfaces. Animations, transitions, effects, gradients, reflections, customised skins, embedded movies, nice charts, changes in opacity, layouts that are resized well when their container is resized, etc. For a demo, check the Flex 2 Component Explorer.
- Working on all major desktops and web browsers and many mobile devices. OS’s: Windows, Mac OS, Linux and Solaris. Browsers: IE, Gecko-based browsers, Safari, Opera. Mobile devices: many, and more to come.
- Keeping the same “look & feel” everywhere. You can see the default Flex 2 “look & feel” in the Flex 2 Style Explorer.
- Integrating and communicating with other Adobe formats. Flash movies, Acrobat documents, ColdFusion, Dreamweaver, etc.
What Flex is not good at:
- Computationally expensive software. As we saw before, Flex stresses GUI aesthetics, intuitive design, portability, compatibility with existing Flash files and other Adobe tools, easy deployment, etc. And it was aimed at the web (in spite of Air). So don’t expect it to be any good at doing system calls, invoking hardware drivers, messing with the network at low-level, fine-tuning loops to save cycles of CPU, dealing with gigabytes of data, delivering real-time, etc. Because Flex apps are deployed as Flash files, every Flex app “lives” inside the Flash security sandbox, which prevents it from accessing many of the resources of the computer. Also, Flash is a proprietary format that doesn’t run natively but is interpreted by the Flash Player. That extra layer of translation decreases the performance.
- Classic Flash stuff. Don’t bother to learn Flex if all you need to do is Flash banners and simple animations. For that you will need a timeline, drawing tools and accuracy at pixel-level. Flex is not designed for that.
- Being extrovert with its neighbours. I hear that even Air makes it quite difficult to launch an external executable from a Flex application.
Now, the “hello world” is mandatory, so here it goes.
This application simply displays a customised greeting (it’s a “hello world” on steroids). We’ll make the GUI inherit from the layer that processes the information, in a “code-behind” manner.
First, the Actionscript class contained in the file info/tripu/blog/flex/SimpleApp.as. This class extends the standard Application class and defines what to do with data:
package info.tripu.blog.flex {
import mx.controls.Alert;
import mx.core.Application;
public class SimpleApp extends Application {
public function greet (who:String): void {
Alert.show ('Hello, ' + who + '!');
}
}
}
Second, the MXML application HelloWorld.mxml. It defines the GUI by using an instance of the class SimpleApp and adding a couple of visual controls to it. Notice how the AS class that we created before is now used straight as an XML element:
<?xml version="1.0" encoding="utf-8"?>
<tripu:SimpleApp xmlns:tripu="info.tripu.blog.flex.*" xmlns:mx="http://www.adobe.com/2006/mxml">
<mx:TextInput id="user" text="world" />
<mx:Button label="Greet" click="{greet (user.text)}" />
</tripu:SimpleApp>
The result of compiling those two files in a Flex project is this Flash file, HelloWorld.swf (you’ll need Flash Player version 8 or above to see the embedded Flash object):
Entries
