Nokia's plans to put Qt everywhere
One of the biggest changes coming to the Symbian world over the next few years is the inclusion of Qt into new devices. Starting with the Symbian^2 platform, Qt will be in our smartphones and providing a new Developer Platform choice for programmers (and come Symbian ^4 it's going to be powering the UI as well). A recent presentation at Over the Air laid out Nokia's plans...
What are Nokia up to though? Well, Pekka Kosonen sat down with a group of developers at the recent Over the Air conference to talk about Qt and where it fits in with the Symbian Foundation plans, and the wider impact it will have. The main point is simple... Nokia realise that they cannot succeed without the "cool apps" that third party developers put out, the apps that "consumers are looking for".
Video demoing Qt "Tower" technology Preview for Symbian
Thus a key part of Nokia's strategy is to have a good offering for the developers. Here it is important to understand that Nokia are taking a three tiered approach. The first is through their service layer, which enables developers to build on top of Ovi offerings, such as mapping and messaging. Nokia will do this by providing access through programming API's, which will enable developers to build solutions on top of the data and services in the Ovi ecosystem. Second is the apps layer which, as well as standalone applications, acts as an enabler for the service layer. The key focus here is going to swing heavily behind Qt and Web Runtime (WRT). Flash and Java will continue to receive support as third party runtime engines. Of course, you can still code natively in Symbian at the platform level, which sits alongside Nokia's offerings for Linux (Maemo) and the Booklet (Windows) range of devices. Crucially, the app layer (Qt) will still be able to call on the platform level to achieve more complex tasks - you'll be able to combine Qt with Symbian C++. The relationship between the two will change over time, notably when Symbian switches to a Qt-based UI layer.
Nokia believes that they need to answer developers' primary concerns of "how to make money by selling applications". Much is made of the market opportunity Nokia's scale gives to developers, but in talking to existing developers on other platforms the general attitude seemed to be "get your house in order – once things change we can talk again". Therefore the change to Qt and WRT (as a cross platform application framework) partly reflects the current attitudes around the difficulty of coding natively in Symbian when compared to other platforms. This helps explain the decision to buy TrollTech, as the first step, then get Qt, as an apps layer, into the mobile platforms. The underlying idea is to provide developers with a fast and easy environment to develop in. "It was easier to buy, as we're not the greatest API developers in the word", pointed out a laconic Kosonen with a hint of humour.
So why go for Qt and not any of the other languages? Because Qt is more than just another runtime – it's a fully cross platform application framework. It does not have the performance and sandboxing (secuity restrictions) issues that are commonly associated with runtimes. The Qt modular class library provides a significant amount of cross platform functionality including database, GUI, browser (WebKit) and much more, which means that many common programming requirements can be met within the Qt framework. This is currently being extended with the Qt Mobility APIs which will bring mobile use cases (e.g. sending SMS) within the Qt framework. Furthermore, Qt also enables you to combine native code with Qt code, thus, in theory, offering the best of both worlds. In other words Qt can call on (use) native APIs when something is not available within the Qt framework.
While Qt will not, in most cases, result in a write once, run anywhere model, it does greatly increase the number of commonalities between different platform versions, thus significantly decreasing development costs. Furthermore Qt is, arguably, amongst the best placed of current solutions to address the hybrid development that we will see emerge as web and native applications merge together.
Example Qt application running on a Symbian phone and KDE. Source: D.C.T.W.Y.C.D.T Blog (recommended reading).
Another key advantage for Qt is that is a mature environment, which is already being used by developers. The chances are you are already using software (Skype, Google Earth, VLC, Adobe Photoshop Album, Last.fm player, KDE) that is powered by Qt. As a relatively modern application framework, it leaves behind a lot of the legacy conventions that have made Symbian's C++ hard to adapt to (if you're used to the conventional approach to C++). Nokia also hopes that it will be better able to entice desktop developers to become mobile developers if it enables mobile development through a familiar framework.
On Symbian, Qt will, intially (Symbian^2 and Symbian^3), be available alongside native Symbian C++. However, with the release of Symbian^4 phones, Symbian's 'native' application and UI framework will be Qt-based. This will replace the existing AVKON framework. However, it is very important to note that the large majority of Symbian APIs (native code) are not related to AVKON and therefore will not be affected; they will continue to be available as before.
A rough estimate suggests that, by the time Symbian^4 is mature, some 10%-20% of use cases will still require some Symbian native code, so Symbian C++ will always be required. However, developing applications that are fully coded in Symbian native code will become more of a 'samurai sword' technique that will only be pulled out when it's really required. If all you need is the butter-knife of Qt then that's fine. Remember, the key is for Nokia is to get more developers onboard and create a comfortable working environment for all. By focusing on Qt (together with WRT), they can deliver that.
These are the sort of things that will hopefully make developers take another look at the largest addressable smartphone platform on the planet, and keep Symbian powered phones at the forefront of the innovation race in the mobile space.
-- Ewan Spence, September 2009. Portions by Rafe Blandford.
Further information related to the Qt Everywhere presentation is available here.
Published by Rafe Blandford, Ewan Spence at 20:32 UTC, September 30th
Categories: Developer
Platforms: General
News Discussion
In the past, it has taken at least year from a new version of Symbian OS to be ready to the first phones on the market with that version. Symbian Foundation is probably not going to change that by much, unless device manufacturers start to use new OS versions on old devices.
In the past, it has taken at least year from a new version of Symbian OS to be ready to the first phones on the market with that version. Symbian Foundation is probably not going to change that by much, unless device manufacturers start to use new OS versions on old devices.
No so much Symbian, but S60, if you want it to do anything fancy (think Gravity app, Profimail UI) then you have to code your own UI features. The S60 stuff only offers those basic text menus that come up when you choose a selection list etc. QT is a framework with that work already done.
I imagine the need to mess with Active Objects time slicing isn't going to go anway any time soon.
Qt doesn't use the Symbian C++ constructs that were designed for devices with little memory, like descriptors, the cleanup stack etc. This makes Qt easier to learn for C++ programmers than Symbian C++.
With Symbian 9.1 you can program the non-UI parts in Standard C++, but not the UI parts, so you are still having to know a lot of Symbian C++ to become productive. Also, combining Standard C++ in the engine and Symbian C++ in the UI needs an adaptation layer, for instance to turn C++ exceptions into Leave's so the UI framework can do it's thing, or turning Standard C++ strings into Symbian C++ descriptors. With Qt there is no need for such an adaption layer.
Qt will not be part of the S^2 distribution. It is a separate install for both S^1 and S^2, but this will pretty much be the same Qt that goes in S^3 onwards. S^3 will be fully compatible with both Qt and the old S60. S^4 also gets the new UI components and native apps, and probably drops S60. (Everything is in the roadmaps in the Wiki on [URL="http://developer.symbian.org"]developer.symbian.org[/URL])
N97 2.0 is pretty much S^2 as far as I can tell. It has the new home screen, kinetic scrolling etc. Remember, there is only 6 months between releases, so there's not always gonna be a massive difference between releases. Compare this to Ubuntu for instance.
As for the timeframe between a Symbian release and phones arriving featuring said release, it will improve. The reason is that it is now the manufacturers and chipset vendors that write Symbian, so the code for S^x has already been with the vendors for a long time before we bless it and formally call it S^x.
The reason we're adopting Qt is that the Symbian C++ is pretty much C++ as it was in 1994, which is... not ideal. Qt is modern. Also the S60 UI was getting old and crusty. With Qt we're pretty much on par with native Android and iPhone, but remember: we also support Python, Java, Ruby and Web Runtime.
I wonder how much of an issue this will be for developers, who may need to include the Qt sis within their application sis (make for big install files and other issues)... That was one of the reasons for the slower than expected adoption of PIPs / Open C as I recall.
I wonder how much of an issue this will be for developers, who may need to include the Qt sis within their application sis (make for big install files and other issues)... That was one of the reasons for the slower than expected adoption of PIPs / Open C as I recall.[/quote]
The problem with OpenC was that S60 3rd edition did not keep track of dependencies properly. If there were two apps using OpenC, both embedding the sis file, the system would remove the OpenC lib as soon as one of the apps was removed. The other app would then crash, and there would be no clear indication of what was happening. That's a big problem, because it generates lots of support issues for developers.
Size is less an issue nowadays, with sideloading, Wifi and unlimited data.
I agree size is less of an issue, but smaller is always better if you're doing something OTA (e.g. Ovi Store).
I agree size is less of an issue, but smaller is always better if you're doing something OTA (e.g. Ovi Store).[/quote]
Agreed. Being complacent about size = bloat.
[url]http://mobilephonedevelopment.com/archives/909[/url]
Main Navigation
|
» Home (1) » News (2) » Reviews (3) |
» Features (4) » Media (5) » Forums M | Full (6) » Top (9) |
Advert
mobile.allaboutsymbian.com