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.

Always fun to try out another framework.

Papervision.

A while back we were commissioned to build a 3D game of Mahjong.
Nothing particularly challenging, simply blocks (or tiles as they are known) moving between players at a table.
At the time however, there were no actionscript 3 based 3D frameworks, so we hacked together a simple 3D API, the bare minimum needed for this particular project. This was fun, but wasn’t going to be much use for more demanding 3D based projects.

A few months down the line and Papervision comes along.
This is an open-source actionscript 3 based 3D framework (in case you haven’t heard of it).
Now, Papervision isn’t the only as3 3D framework out there, but it is surely the most heard of and most actively developed, and hence worthy of a CJT workout.

We were lucky enough to be asked to quickly knock out a mapping widget for a page in one of our sister companies, Creative Jar, contracts.
As we have a great deal of swf based mapping experience (statmap, maplecorft maps) and some good old 3D maths experience, we took the opportunity to take Papervision for a ride.
We needed to create a stylized, yet fairly accurate, globe of planet Earth, with locators placed at various longitude and latitude coordinates.
So we’re talking a sphere and then wrapping an image onto it. Parsing some XML with the data to map, in this case some hotspots/locators, that when rolled over display some location specific text. Each locator needed to be positioned on the globe via its longitude and latitude coordinates. The globe also needed to be rotated via mouse dragging.

So, Rob at CJ supplied an image of how the thing should look. Our challenge was to replicate the look, get all the interaction in, and do it in a day or so! Oh yes, and make sure it was fast and a small download.

Now, the first gripe with Papervision was interactivity. This can only be achieved by adding listeners to interactive materials. This, in our opinion is unintuitive. We would expect to simply say “this object should be interactive” and then the object emits mouse and keyboard events upon user interaction.
When loading a Collada file into Papervision however, you have to iterate the loaded objects loaded materials (and only when they are done loading) and set them as interactive. This is a shame and is a common gotcha for many new users to Papervision. Anyway, we write what’s required and off we go.

Next… We quickly found that by using all the available run-time shaders and lighting, rotating the globe was seriously slow. We quickly realized that this runtime shading/lighting (and there was lots due to Rob’s fancy design) was simply not needed and could be mimicked, so we got a very sharp speed increase from faking it. Of course in an ideal world, Papervision would be clever with its rendering and work out that the lighting and shading didn’t need to be reapplied to the globe on every render, but equally we didn’t need to apply it in the first case.
This wasn’t a Papervision bug, more a simple hack to get render speed, and in 3D programming, its all about the hacks – ask any 3D game programmer!

The final gripe (although gripe sounds a little too strong) was that of the development of the framework itself.
There are lots of check-ins to the source code repository, and over a few days, we found one check-in breaking functionality somewhere else. Really there just seemed to be no QA on the check-ins. For example changing a rotation attribute with a range of 0-100 to 0-1 for example, therefore breaking the API and any other component expecting 0-100, was this really needed? Was it not possible to delay the check-in until sufficient testing uncovers any bugs introduced from an API change?
The upside of this attitude to allowing check-ins with minimal testing, is that development moves very quickly, the downside breaking compatibility.
I doubt we could checkout the latest Papervision (lets say because it had some new piece of functionality we wanted to make use of), build our mapping widget and expect it to work without change and hunting out what change in Papervision caused the breakage.
We have worked with (and contribute to) a number of open-source projects, and the most friendly for end user developers are the ones well coordinated, so an API breaker, would be thoroughly discussed and tested before being committed.

Now this is not a knock Papervision rant, as in our opinion, Papervision is a superb piece of work from some very talented people.
They have brought a fantastic framework to the community of as3 developers.
My round-up would simply be, with a little QA, this could become far more developer friendly and hence uptake would be even greater than it is now.

For anyone interested, here is the resut of this particular experiment.