Anyone who has been developing for Symbian will well know of the constraint of having to use MS Windows to do the development on. Windows is the only ‘supported’ platform even though much of the tool chain is based on open source components easily compiled to Linux and OS X. There are workarounds, such as the efforts of Martin Storsjö here, which is how we currently do it in our offices, as we predominantly use Mac’s and Linux machines for development.

With Nokia open-sourcing Symbian, I for one have been hoping for some effort towards making the SDK tool-chain cross-platform.
The Symbian Foundation have been releasing various code and initiatives, but as yet there is no mention of any work towards making the SDK tool-chain truly cross-platform. Lets just hope at some point this happens though, because as good as Martin’s work is, its not ideal and is always playing catch-up to Symbian releases.

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.

So Nokia have made a change to the licensing model of its QT framework.

The QT framework is a cross-platform C/C++ GUI framework developed by a Norwegian company name Trolltech which Nokia acquired last year. Anyone who has been doing cross-platform C++ applications with a GUI will have come across this framework and / or used it at some point.

However, the previous licensing model was very restrictive.

The only platform you could freely develop for was Linux – if you wanted to use QT for Windows, Mac or any other QT supported platform, you had to purchase a (not so insignificantly priced) license for each platform.
This model really locked out independent developers and small development companies as the cost was simply too great. This will surely have hampered adoption of a quite easy to use and polished framework.

And this is where Nokia’s move to the LGPL (GNU’s Lesser General Public License), an open source license, should really impact on the adoption and usage of the framework (and of course extra development!).

Personally I use and also like to contribute to the superb wxWidgets open source cross-platform GUI framework. It has great platform support, is well written, has a large community behind it, uses native controls etc etc – the list can go on.
However, QT also has many benefits too. I can imagine there will be occasions when QT would be a preferred choice, for example on embedded devices.

I certainly welcome this move and am looking forward to using QT more.

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.

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 CJT, 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).