Adobe Flex for MV GUI
I’ve been looking at Adobe Flex. I think you may be interested.
As soon as someone says "Adobe" most people think "PDF". That’s just a part of their offering. And if one says "Flex" many people think "Flash". That leads to thoughts about glitz and animation and all of those things that are really wrong for business application software. Let’s fix some of those misconceptions.
Flex is software used for creating Rich Internet Applications – or RIAs. The focus of Flex is on things like text boxes, buttons, lists, etc – the sort of things that business software developers like. Flex happens to deploy in the Flash browser plugin. The Flash plugin happens to be used for both Flex RIAs and for Flash animations. With me so far?
Flash projects create SWF files. So do Flex projects. With Flash, you put images on a form, create a timeline to guide what the animations do at specific points in time, and use some code to manage events. With Flex, you drag/drop controls on a form, and use code to manage events like Click, Change, etc. If you’ve used just about any other GUI IDE like Visual Studio then you know how most Flex apps are created.
For both Flash and Flex, after making code changes you compile your project to an executable, which is contained in a SWF file. If you were using Java this would be a JAR, for .NET it’s an EXE or DLL, etc. To see the results of your effort, an HTML file uses an Object or Embed tag to define the SWF file – many developers use template HTML to deploy their SWF files and never even look at that code. Java would similarly deploy as an applet. For .NET to deploy in a browser, you need Silverlight – I’ll get to that in a bit.
So what does Flex look like?
Flex is a combination of XML and JavaScript, and very little more. You don’t even need to bother with the XML, it’s really just there as a convenience. Pretty much anything significant in Flex is done with script. The JavaScript that is used in Flex is called ActionScript. ActionScript follows the latest ECMAScript standards just like any other JavaScript but also includes features that are in the as-yet-unapproved spec for the next version of JavaScript – so you’re getting a stable but advanced version of what everyone else will be getting whenever the spec is approved. In addition to this, an extensive library of functionality is provided for ActionScript. Where JavaScript provides basic functions for Math, Dates, and String handling, ActionScript provides much much more.
What’s with the XML?
Developers like to create apps in a GUI IDE. Flex generally uses XML as the source for IDE code to render common controls. So when the IDE sees <mx:Label text="Hello"> or <mx:Button label="Submit">, it draws a label or button. The XML syntax with Flex-specific identifiers is called MXML (think Macromedia who came up with this stuff in the first place and Adobe then acquired them). When code is compiled, the MXML is transparently turned into script code anyway. Since it’s easier to do some things in XML, or more readable anyway, Flex developers will define visual aspects of their UI with MXML but add functions in ActionScript to do the real work. Some functions simply can’t be done in XML so learning the script is required.
What confused me when I first started to look into Flex was how the MXML and ActionScript relate. XML isn’t code so how does that work? And I don’t see anyone creating XML controls in application code, so how does code "control" XML? Remember that the XML is translated to code at compile time, so the button XML above would compile down to something like:
var btn1:Button = new Button();
btn1.label = "Submit";
So application code doesn’t manipulate XML for the UI at all. The XML disappears into code during the compile, so application code is working with objects exactly as if the application code itself had defined everything – and it can if you wish, but most Flex developers find the XML convenient for defining the GUI layout.
The GUI IDE I’m talking about is called FlexBuilder3. FB3 is essentially the Eclipse IDE (free and open source) with a ton of plugins to make the environment aware of Flex.
IDE? Free?
Uh, yes and no. Eclipse is free – and open source – as are many plugins created to allow various types of development with it. The Flex SDK libraries are actually free and open source as well. However, the FB3 IDE which brings together all of the tools is not free. It is offered by Adobe for the trivial sum of about US$300. Compare this to other products in the same area.
You can download the Flex SDK, write your XML and ActionScript in an editor of your choice, and compile and run the code entirely for free – but most people say the FB3 is worth the nominal cost.
Personally I find the FB3 IDE to be clunky, rarely helpful, missing some basic features, and otherwise a very amateur implementation of an IDE compared to most other development tools. IMHO it’s a good thing Adobe only charges $300 for it. If all you care about is render XML graphically and moving controls around rather than hand-code all of the UI details, then FB3 is probably worth the price. (I’m sure comments like this won’t win brownie points with Flex fans – oh well.)
5 thoughts on “Adobe Flex for MV GUI”
Leave a Reply
You must be logged in to post a comment.
I for one will be using silverlight in the next 12 months – i already use both asp.net and javascript , tho the javascript is just fairly noddy web page stuff , so silverlight is the natural choice – to be able to code in .net inside the browser is pretty exciting stuff.
I didn’t mention AIR for running Flex projects on the desktop, nor did I mention that the Silverlight XAML is the same code used for WPF – the .NET 3 thick-client way to create a desktop. These tools are sooo close in design. The choice is probably more a matter of comfort more than anything. Another colleague tells me he won’t ever touch SL. Great. As long as people are adding value and selling their MV apps, I don’t care what they’re using.
The only "problem" I can see with Flex is that it absolutely does not work on phones. "Web" apps can be written to degrade and work where there is no Flash. Of course you can send people different places, but then you’re into maintaining two apps.What I do like is the complete platform independence – Flash is Flash. And you get AIR too…
The following is fairly recent Ross. It’s really tough to keep up with this stuff.
http://www.adobe.com/devnet/devices/index.html?navID=gettingstarted
http://www.readwriteweb.com/archives/flash_10_for_mobile_devices.php
Related: http://arstechnica.com/software/news/2008/11/adobe-to-close-desktop-mobile-flash-player-gap-with-arm-port.ars Note these mention AIR for mobile as well.
http://www.techcrunch.com/2008/03/17/microsoft-adopts-flash-lite-for-windows-mobile-as-a-stopgap-measure/
http://www.linuxdevices.com/news/NS5010205574.html
Even given those links, there is a question about just how much can be done with Flash on a mobile device. More important is the question about whether Flex and RIA (business applications) can be deployed over mobile now or in the near future. Note the distinction between Flex and Flash in the blog/article – they both happen to deploy with the Flash plugin, but does Flash-Lite also support Flex? I have no clue. Given the lack of response to my blogs on PDA development I’m not sure how many people are even interested in mobile devices, so I won’t be doing any research on Flash/Mobile unless there is a business case. If someone has verified recent information about related details, please post here or email.