In my previous post, I described how the architectural frameworks that have sprung up for flex/actionscript developers are not the best thing since sliced bread for implementing well designed applications.

They attempt to take the design pattern, MVC, along with some other design patterns and bring them all together into one monolithic architectural framework.

However, you do not need to use these frameworks to program using the MVC pattern or indeed any of the other patterns used in these frameworks.

So for those developers who understand the various design patterns already, and are opting not to use these architectural frameworks, I present something I feel rather useful in terms of actionscript and the MVC pattern inparticular.

As you will already be aware, in the MVC pattern, you ideally want the actors (the Model, the View and the Controller) highly decoupled.
Therefore its common to see the coupling achieved via notifications (the observer pattern AKA publish-subscribe) or some other kind of eventing.
In actionscript 3, its a very common practice to make use of events, as the event model (an implementation of the W3C DOM event model) is built in.
However, the bubbling and capture phases of the event flow only work when the dispatchers are part of the display list. This means events can only flow when the dispatcher is a view element.
Therefore anywhere else, you need to tightly couple to the dispatcher in order to receive events from it. Not ideal.

This brings me onto the Objective-C/C++ NSNotificationCenter found in Apple’s Cocoa API (and of course the GNUstep framework).
This a very elegant, lightweight, fast and easy to use class.
The usage is simple…

1. Any object which wishes to send a notification, can easily send one via the NSNotificationCenter’s postNotification method (or its variations).
2. Any object wishing to observe notifications can observe via NSNotificationCenter’s addObserver method.

The most useful part of this is that the observer can choose to listen for specifically named notifications, specific senders of notifications, both by name and sender or listen for *all* notifications regardless of name or sender.
It is up to the developer what level of coupling to use.

Users of the NSNotificationCenter most commonly make you of a static instance retrieved via NSNotificationCenter’s defaultCenter class method, though of course a more compartmented usage can be achieved via instantiating multiple NSNotificationCenter’s. One such usage could be a more modular application whereby a module wishes to have certain module private notifications, yet also publish and subscribe to the rest of the application.

Actual notifications can either be NSNotification instances or instances of sub-classes of NSNotification.
By creating sub-classes, you achieve a stricter interface, though as you see in Cocoa, this is an uncommon practice.

I am sure anyone already familiar with these classes will understand, they can be very useful indeed.
As such, I have ported NSNotificationCenter (and as such also NSNotification), into actionscript 3 (and also into C/C++ while I was at it) for all to use.

Full source code including example/test applications for download here.

Update: Download link now also contains JavaFX version as well.

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.

So, JavaFX v1.0 was released the other day and many people are quick to have a rant about it, so I may as well chip in too!

We have lots of commercial Java experience, both on the server and the desktop, so have kept a keen eye on JavaFX since it was first announced – which feels like ages ago, and its this point I will address first…

Its difficult to generate a community around a new technology which has been prematurely announced (i.e. before its even really in an acceptable beta) and delivered way later than first scheduled (approx one year behind schedule).
Encore are a company I can only imagine Sun would love to become an early adopter of JavaFX – cross-platform, multi-device, many on/off-line applications (and RIA’s) developed by us and of course lots of Java experience. But its been difficult to get behind the technology. We need to be sure it can deliver both technological advantages and user experience above its closest competitors (Adobe’s AIR/Flex and to some degree Microsoft’s Silverlight).
Since first announced, its felt very alpha in its development. We, the community, have been informed what it will be, but it just hasn’t yet delivered.

Now lets take a step back and address the points we like.

- The JRE.
The maturity of the underling technology (the Java Runtime Environment) cannot be overlooked. One of the biggest gripes we have with, for example, the Flex framework, is it is bug ridden. Start doing any kind of serious project with it and you cannot get away from this. The mx components have been completely re-written no less than three times now! And they are still buggy. This slows development, there is no getting around it. Ask any developer who has done any serious stuff with the Flex framework and they will be able to testify to this. Hopefully with Flex, this will improve now that the framework is open-source.
Java is very mature and so we shouldn’t see soo many issues in this department.
The JRE is also leaps and bounds ahead of the Flash Player in terms of functionality, along-side the fact there are tons more Java developers (and more experienced) out there than actionscript developers, which as an employer, is also a key point. Finding decent actionscript developers is tough compared to experienced Java developers and this isn’t because of demand, its because actionscript 3 (I pinpoint 3 because 2 was half-baked and the Flash Player AVM1 was pants compared to AVM2 – hence incomparable to Java and the JRE) is a relatively new language and most actionscript “developers” have come from a creative/design background as opposed to programming. We like designers to do design and hard-core coders to code and for the two teams to collaboratively work together to create great results.

- The delivery mechanism.
The fact JavaFX is part of the JRE, anyone with a recent JRE will already have the JavaFX runtime installed.
Sure, there are always going to be cases where a users JRE will need updating, but Sun have been making lots of effort to make this easy and a small download. As time goes by, this will just be less and less of an issue alongside Sun making the install experience easier and better. This is more a JRE issue than JavaFX as Sun have been overhauling the Java install experience anyway.

- The on/off-line capabilities and user experience.
Seriously overlooked is the ability to simply drag a running JavaFX application from the browser window to the desktop.
The coding of one application and the ability for end users to either run it from the browser like any other RIA or install it locally as a desktop application by simply dragging it from the browser window – this is cool. If the user does drag it to their desktop, you can leverage all the extra desktop functionality and thus create some great user experiences.
Adobe developed AIR to essentially fill this gap the Flash Player and Flex framework had, but they just haven’t thought this out as well as Sun in my opinion. If you take an Adobe route and want browser and desktop application, you end up writing two separate applications and have two separate end-user install requirements, the Flash Player for browser app and AIR for the desktop app.
Take the proposed Sun route, you have only one requirement, the latest JRE. You also have only one app to develop.

- Mobile.
Not yet delivered (though apparently in Spring 2009) is JavaFX Mobile.
Given that there is a JRE on practically every mobile phone in the wild, you can see where JavaFX plans to reach.
Compared to the Flash Player in this department, JavaFX would win hands down. Flash Player on mobiles, named Flash Lite, is years behind its desktop counterpart (Flash Lite is still the old AVM1 running actionscript 2 coded apps) and Adobe are only now starting to talk about AIR on mobiles in the future, no firm dates.
Even if Adobe updates Flash Lite (so AVM2 and actionscript 3), it will still seriously lag behind Java functionality on the devices.

Brining it all together, if Sun can deliver and then get companies to adopt, JavaFX is going to be a force to be reckoned with. Develop one application that can run through a browser, on the desktop, on mobile phones/devices… brilliant. But its a big ask. So far just delays and a beta-like release. I guess more will become clear how this is going to pan out over the next few months.
Many are quick to write Sun off – I am not soo quick.

Recently we have been working on another web app – or RIA as some would coin.
When we do server side stuff at Encore, we often make use of Java, J2EE more specifically.
This particular project required a flex front end.

On the server then, we do our usual hibernate for persistence and spring for the IoC which all yields a nice well designed and configurable server side web app.
What made this job a little more interesting was we wanted to have a play with one of Adobe’s recent open-source contributions – BlazeDS.

Among other things, BlazeDS gives us remoting, which is what we wanted for this particular project. We can call our remote Java services and pass actionscript objects to the server, these are serialized to and sent over as AMF. BlazeDS (the server-side J2EE web app), deserializes this AMF into Java objects. When returning objects to the client, BlazeDS serializes the Java object(s) and then the client side flex app, deserializes the AMF back into actionscript objects. Neat.

However, all good and well, what happens when you want to integrate BlazeDS into the rest of your J2EE infrastructure?
Luckily enough, BlazeDS does allow for the configuration to assign a factory class to deal with looking up your services. So we write a factory that returns Java beans (our service classes) we have configured via spring. BlazeDS calls the appropriate methods on the service bean passing in the deserialized AMF method parameters. The result is then serialized and sent back to the client flex app. Sweet.

One gotcha we faced was this…
As we are using hibernate for persistence, we could (and needed to) make use of lazy collections. That is, when a persistent object holds any kind of collection, hibernate can return empty proxy objects in the collection that only actually retrieve the value when the caller asks for it (eg iterating over the collection). This is a great way to reduce overhead, but Blaze’s implementation just doesn’t handle this out of the bag, so when returning a lazy collection, flex simply couldn’t retrieve the objects in that collection.
Now with large tree structures of data objects, we couldn’t simply switch off the lazy loading in our hibernate mappings to allow returning to flex the whole object tree, so we had to look to keeping it lazy. Not difficult, we just had to add in the necessary service calls for this projects data model.

In summary, we got BlazeDS, hibernate and spring all working together nicely, just would have been nice if BlazeDS handled lazy collections for us. They are commonly essential for an enterprise level application.
I would say, at the moment, the superb Granite Data Services is a better option at present over BlazeDS.
It handles all that BlazeDS does and more. It also deals with the lazy loading issue

References

BlazeDS: http://opensource.adobe.com/wiki/display/blazeds/BlazeDS/
Granite Data Services: http://www.graniteds.org/
Spring: http://www.springframework.org/
Hibernate: http://www.hibernate.org/
AMF specification [pdf].