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.

A new Google research project then… Native Client.
This is being discussed all over the place, but here are my thoughts.

Basically this boils down to a browser plug-in that will load and run compiled x86 modules (for want of a better word). This is native byte-code.
What the Native Client plug-in adds is essentially some security, a sandbox, to your native byte-code. So essentially your module cannot do ‘dangerous’ things in the browser.

As usual, we have pro’s and con’s…

We get speed, and to some, degree cross-platform ease.
Obvious speed enhancements over other runtimes is the use of native byte-code. No JIT compilation for example.
And cross-platform, yes, so long as your compiling to the x86 processor and using the supported library calls.
Also a standardized way of running native byte-code without having to create a browser specific plug-in that end-users need to install and trust.

I think this last point is quite interesting.
Is there really any good reason why you wouldn’t just write a Netscape Plug-in?
That’s what the Native Client is after all.
Well there is the obvious trust issue. At install, more end-users will trust an install of a Google plug-in than company xyz’s. And if the technology takes off and becomes ‘accepted’ then companies like ours have a fairly easy way of coding client side, cross-platform (so long as x86), processor intensive browser based modules.
However, is there really such a demand for this? We have faster and faster JavaScript engines, decent RIA platforms (Flash Player/AIR, Silverlight and hopefully JavaFX).
Well, in specialized cases I can certainly see advantages (e.g. client side specialized image or sound processing for example) but this is not the norm and so leaves this question:
Assuming we are tasked with developing to such a case, do we develop a module for Google’s Native Client plug-in, hope that the user already has this installed, and if not they are happy to install because it’s a Google plug-in?
Or just create our own browser plug-in (which is what Native Client is remember, and we have written many of before) and digitally sign it (so end-users don’t get loads of browser warnings at install time). After all, its usually a specialized market so there will be brand trust already.

Now, these are only first thoughts, I have yet to take the technology for a thorough test drive.
These first thoughts do leave me with this doubt that the technology will take off in a big way.

One thing is for sure, they have done some cool/clever stuff in the sandbox implementation – static analysis of the instructions and dealing with self-modifying code trying to overcome this analysis.

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.

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