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):