Follow-up to Flex: MVC frameworks comparison from [Ux]

First attempt at refactoring the recorder app to Cairngorm today; after trying and struggling slightly to get going with the PureMVC version (mainly because I couldn’t find a ‘getting started’ guide that worked for me and the official courseware is a closed beta) I decided to give Cairngorm a go.

Using Rob’s Simple Cairmgorm Application guide got me as far as having a skeleton framework, then I spent some time watching these excellent video tutorials by David Tucker. After modifying my existing classes and components to fit the framework eventually I got something working.

At some point I underwent one of those defining moments when something clicked in my head and now I can clearly see why this MVC stuff is A Good Thing. I now have much clearer separation of my data/value objects from my views, and can let the controllers handle events and commands. This also helped me rethink and rationalise the application design; starting with my basic views as MXML components and a simple ModelLocator, I could then define what events would trigger a view or state change, then register all those events and their Commands using the AppController. For me it was a big shift in approach and understanding.

This application doesn’t use VOs very much, but it has a lot of asynchronous states and timer events to manage, so it will be interesting to see what I end up with.

Writing about web page http://maliboo.riaforge.org/

Interesting project on Sourceforge that uses flash.net.Socket to allow Flex/AIR applications to use FTP. I got this via RIAForge where there’s a bunch of useful and upcoming libraries for use with Flash, Flex and AIR.

Writing about web page https://admin.adobe.acrobat.com/_a200985228/p12266504/

As I’m about to move into using an MVC framework for Flex applications, I thought I’d have a look at what’s currently available. Rob has already done some work with Cairngorm, which is the solution suggested by Adobe, but there some others out there too, including PureMVC, Model-Glue, and Guasax, plus a few others I hadn’t heard of before, although some of these were immature or dormant.

The guys at Pattern Park recently conducted a comparison of the frameworks available. They scored each framework’s effectiveness using three main criteria – Approachability (how easy it was to set up a project and get started, the level of documentation and support), Scalability (how ‘expensive’ is it to add features, how ‘testable’ the code is), and Flexibility (is it open-source, can it be modified, is it context-independent etc.).

The presentation is well worth watching, but they concluded PureMVC scored most highly in all three criteria, with Cairngorm coming close behind. However as someone noted in the presentation, knowing Cairngorm is a prerequisite if moving between clients because many existing projects will be using it already. Luke Bayes has a follow-up to the presentation where these points are mentioned in greater detail.

Here are their reasons why PureMVC came out on top:

• Composition over inheritence
• Liberal use of Interfaces
• Indirection is used but not overwhelming
• Instance members hide singleton references from application code
• MXML views can be extremely thin
• Benefits of Cairngorm, with few of the disadvantages

The presentation is very useful for anyone considering patterns/frameworks for Flex development – I’m going to start working with PureMVC this week and see how it goes…

My PC at work looks like a bowl of spaghetti right now with cables everywhere, most of which are coming out of the Viewcast Osprey 440 capture card it now has installed. The Osprey is a 16-channel 64bit PCI-X card, but as my machine only has standard PCI slots I’m only working with 2 inputs, connected to a pair of DV cameras.

The 440 is Video-for-Windows and DirectShow-compatible which means the input channels can be accessed and read by Flash Player. Each primary input channel (there are 4 main inputs via BNC) is listed in the player, so by using a version of the code I blogged in a previous post it’s possible to create an input switcher in Flex for all 4 primary channels by parsing the device list and providing a means of selecting an input. It’s also possible to have all 4 channels running simultaneously and the input switching provides a basis for a software ‘mixer’. That’s the next job…