Ola Bildtsen

I recently did a “tech talk” at work — an introduction to Adobe’s Flex and AIR. The presentation is geared to the techie with some UI-building experience but with little or no knowledge of Flex or FlexBuilder.

Although there are some high-level introductory/overview slides up front, the bulk of the presentation is a build-it-from-scratch session that shows how to use FlexBuilder to put together a simple Flex app (the obligatory Twitter client).  It also shows how to work with a library project, and then goes on to create an AIR application using a shared component.  Towards the end, I’m firing up FlexMonkey to show how to test the Flex app we built and how to generate the scripts and AS3 code needed to integrate those tests in a CI build.

The slides are here. There are not that many, but there are some useful links on the last slide.

The Flex projects built during the presentation are here.

We recently re-wrote a fairly major Flex application, having an opportunity to start from scratch with lessons learned. The previous implementation used the Cairngorm framework, but not quite in line with its intent — it was purely used to in “data commands” to retrieve data from the server.

After reviewing some of the other MVC frameworks out there (PureMVC mostly), we decided to stick with Cairngorm but to expand its use to the full extent it was intended. In our mind, that meant to have Cairngorm events/commands handle all user gestures (unless they were trivial, component-local gestures like re-sorting a datagrid, etc.). This worked great, and we were pretty happy with the emerging structure of the application except for one thing: we didn’t like the ViewHelper/ViewLocator pieces. It seemed too cumbersome and overly structured for the simple task of having a command communicate with a view. We also didn’t like to control views from commands via the ModelLocator (as also suggested by the Cairngorm docs), as we had tried that in the earlier version and it quickly became a disastrous mess of spaghetti bindings that were incredibly hard to unravel, much less maintain.

Continue Reading »

At work, we recently had an opportunity to rebuild the Flex front end to our web application. Having started from scratch with the initial version of the application a year and a half ago (with little prior Flex experience in our staff), this “greenfield” opportunity gave us a chance to take the lessons learned (and new stuff available in Flex 3) and apply them to the new project. One important change, from an architecture point-of-view, was the introduction of modules and how to make them work with deep-linking.

Continue Reading »