So, last week Adobe moved Alchemy onto the labs website.

I have been interested (and genuinely excited) in this project from the first murmurs of it.
C/C++ to AVM2 byte-code. Sounds great for our development team. We have loads of cross-platform C/C++ skills and very good knowledge of the Flash Player AVM [pdf].

So I have been racking my brain on some really cool uses for it.

The most obvious benefit of Alchemy is that of re-using the vast amounts of already written C/C++ code out in the wild and what we also have in-house.

This however, is not without issues…

To make use of existing C/C++ code it must firstly be platform independent (or at least have very little platform dependence) and secondly be portable to the Alchemy compiler.
The next issue is that of relevance. Is it really worth the effort porting existing C/C++ code to compile against the Alchemy compiler (and I can assure you this is not going to be trivial in 9/10 cases) when you may as well do a language port – e.g. re-write in AS3?

At the moment, there are possibly a few cases where using Alchemy will yield a speed increase over compiled AS3.
This is because the current Alchemy compiled byte-code makes use of a couple of undocumented AVM2 op-codes. However, I assume these speed improvements will filter down to the actionscript 3 compiler at some point.

So whats the future for Alchemy?
Lets assume that these undocumented op-codes get used by the AS3 compiler so that there is no speed advantage of Alchemy and that porting existing C/C++ code to compile with Alchemy takes significant time.
This leaves no advantage at all.
However, lets assume Adobe choose to keep Alchemy with speed advantages over the AS3 compiler. They would then have a commercial product offering for specialized use cases.

So AIR 1.5 has now been released.

Well, apart from the inclusion of the latest Flash Player (version 10) and updated WebKit, what does it really add to the previous version?

Very little in my opinion.

The single most developer requested feature is still surely that of executing external applications.
This really is a must piece of functionality for desktop applications, yet Adobe seem quite content not to add this functionality to AIR.
It is such a shame they are delaying – and I say “delaying” because I am confident they will eventually add this functionality.
I feel they have enough people working on AIR that remember the days of Macromedia Central – and anyone who knows about that technology will know what a flop that was!

Well… its OK for the developers who use our product Shu, as this does at least add this missing feature (among many others).

While talking AIR and Shu, we have a nice new addition coming soon. Watch this space.

We are well known for our ability to create multi-platform, multi-device software applications, so here we spill some of the beans on how we achieve it.

One of these things is language.
There are two distinct ways of authoring cross-platform desktop applications:
1) Use a common runtime environment (e.g. Java – JRE)
2) Write code that can compile down to native byte-code with platform specific switches/defines (e.g. C/C++).

So the first approach…

By using a runtime, such as Java’s JRE, you have a few benefits.
The main benefit is coding only to one environment and letting the runtime deal with the platform differences.
There are however two important drawbacks that can rear their heads.
Firstly, the ideal of “write once, run anywhere” is (and is not Java alone here – from which the phrase comes) often simply not the case.
Secondly, you simply don’t get the speed and direct advantages of programming directly to the platform.

By writing code that gets compiled to native byte-code (e.g. C/C++), you have opposite pros and cons.
You get the benefits of being able to exploit platform specific functionality and low-level speed, but have the drawback of needing to compile to each platform, which involves knowledge of each specific platforms API’s and a good structural design of the code base so you are not maintaining several different code bases for the same application.

Here is the tricky bit, which path do you take?
Simply put, the answer depends on the project.

Here at Encore, we analyse project requirements and make technology decisions based upon them.
It really is a project-by-project decision to be made to achieve the correct answer (it also involves taking a step back and thinking of whats best for the project rather than what you know or like best).

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].

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 Encore 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.