Flash/flex developers have been bombarded by so called MVC frameworks (I say ‘so called’ because they are not really MVC frameworks, but rather a collection of design patterns, including the MVC pattern).

This is partly to do with the evolution of actionscript, from something very rudimentary, simply to help add some interactivity to animations, to procedural, to semi-object orientated and then finally to the fully object orientated language it is today.

It is also partly to do with the fact that actionscript has mostly been used by designers, not developers, and hence many designers have become developers in-line with actionscript’s growth.

So why have all these architectural frameworks been raining on the actionscript community? No other language attracts this kind of attention. Its not because actionscript is better than other languages or because its in greater need for these kinds of frameworks than any other language.

For the most part, other OOP languages are largely used by developers who already understand the principals of OOP and design patterns.
There is no need to develop an MVC framework for developers to use – MVC is a design pattern.
Developers make use of design patterns to create object orientated solutions to common problems in software design. This does not mean the liberal application of every design pattern ever conceived to every project you work on, but use them where they solve a problem, where they make sense.

I guess this is my biggest point against frameworks like PuveMVC and Cairngorm.
By attempting to create a basis for good software design, they can actually fail by creating over-designed, or even badly designed, applications by failing to recognise an applications specific domain needs, requirements and problems.

There are positive benefits of these architectural frameworks too however (if used where appropriate).
Firstly they enforce development teams to work to the same prescribed architecture.
This mostly benefits teams with some novices in the wings. They need not understand why the patterns are used, or how the framework implements it, they just read the documentation and the tutorials of the framework and off they go.
Secondly, and due to the first point, it makes it easier to hire people (and I am speaking specifically for flex/actionscript developers). If they have a working experience of one of these frameworks, it makes it less risky for the employer. There are plenty of very inexperienced actionscript developers out there (due to the evolution of actionscript and its community).
Therefore, with a mixture of well skilled and not so well skilled developers, these frameworks really help bridge the gap.

So, lets say you already have highly skilled developers.
There can be good cases to not use these architectural frameworks for some, even several, applications.
In this scenario, your team will author code that makes use of the correct design patterns as and where needed.

My next post will introduce what should be a highly useful class to actionscript developers not using one of these architectural frameworks.

We have finally got around to releaseing our brand new version of Shu!

It really does complete our product offering for Shu as it allows developers to add extra functionality to their AIR applications whilst still making use of the sanctioned AIR installation model.

Our previous versions of Shu are now renamed Shu SA (standalone) and Shu SA Lite (standalone Lite). These versions of Shu create standalone applications from AIR files.

The new version of Shu works within Adobe’s licensing model of normal AIR applications. We just add the extra power that the AIR runtime lacks (e.g. executing other applications amongst other things).
This also means that developers can sign up for Adobe’s standard AIR runtime redistribution agreement.

This new version also makes it a breeze to create custom installations of the AIR runtime and the AIR application.

So if all thats required is a standalone application with no extra functionality:

Shu SA Lite

If a standalone application is required but with extra functionality not offered in AIR by default:

Shu SA

If the standard AIR installation model is sufficient but extra functionality is required:

Shu!

Check out the Shu website for further details.

Well we have spent some time now playing with and investigating JavaFX.
I wont go over some of the big positives I recently discussed but instead will focus on one particular topic – GUI components (or simply referred to as ‘components’ for the rest of this post).

Well here is the problem with JavaFX version 1 release and components – that is the lack thereof.

What is there then?
Well, there are some (certainly not all) wrapped Swing controls – these are the  components in the javafx.ext.swing package, then there is the JavaFX native javafx.scene.controls.TextBox and finally a couple of layout classes in javafx.scene.layout.
But this is nowhere near what I would call complete and a long way off what Sun are intending regarding a component set for JavaFX.

The problem seems to be we are stuck somewhere between using Swing components (which are wrapped in JavaFX classes to achieve such niceties as data binding) and using native JavaFX components which are intended to be nicely skin-able.

There are a couple of issues with the Swing based controls: 1) they are not style-able/skin-able and 2) they will apparently not be available on the mobile platform.

The issues with the native JavaFX controls is simple… they only have one so far!
These native controls will be great and provide the all important skin/style-ability.

So where does this leave us?
I for one am eagerly awaiting Sun to provide a full set of JavaFX native components. When this happens, I  don’t really see the benefit of making use of Swing based components. In fact it feels like Sun have only created a few Swing wrappers simply to provide some components for this first release. Will there be any benefit of have two distinct lines of components (Swing and native JavaFX)? I dont really think so.

It is vital Sun address this matter more than any other if they wish to see widespread adoption of the technology.

Its a shame the first release didn’t have a full set of components as this is often one of the more important aspects of general uptake.
One of the first things developers will ask themselves is “How good are the GUI controls and layout classes?” and “Are these controls easily skin-able?”. At the moment the answer would be “Not good enough yet.”

“Yet” being the important word to take though. I am sure Sun will sort this out. In fact in a way I am pleased they didn’t rush a set of components out.
Anyone who has worked with Flex (mx components) at any serious depth for any serious length of time will know one thing – they are buggy as hell! The mx components (if you go back to Flash) have been re-written no less than 3 times from the ground up!
The latest iteration being in Flex Gumbo, not yet released. So not speaking for Gumbo as I have yet to review it in depth, but all previous mx components have been rushed and poorly written (hence the re-writes rather than fixes).

The ball is firmly in Sun’s court. The next release will be a vital watch point.