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...
Read on in the full article.
which phones will be released with symbian^2, or is that not on nokia's roadmap yet?
Nokia has not announced any phones based on Symbian^2 yet.
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.
Could somebody please explain to me why coding in C++ within Qt is supposedly easier than coding in Symbian C++.
neilhoskins wrote:Could somebody please explain to me why coding in C++ within Qt is supposedly easier than coding in Symbian C++.
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.
neilhoskins wrote:Could somebody please explain to me why coding in C++ within Qt is supposedly easier than coding in Symbian C++.
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.
Thanks, that's interesting. So in terms of complexity and difficulty, will developing a nice-looking app in Qt be comparable to developing a similar app for, say, Android?
I have never developed for Android so I wouldn't know. But I can compare it to iPhone OS, and the idea is that developing for Qt should be as easy as developing for iPhone. That is going to be tough, though not only because of the platform, but also because of the tools. Xcode is a better development system than Eclipse, mainly because Eclipse is slow and has way too many features. Qt does have the advantage at doing low-level stuff as much of that is simply impossible in iPhone OS, at this time. What would be really cute (sorry) will be Qt on iPhone OS 😉
XCode being better than eclipse is an opinion. I don't like XCode at all, and eclipse is OKish for me. With QT you can use Visual Studio and QT Creator, maybe it will be possible to use them with Symbian (if not, at least it will be possible to use the for the non Symbian specific parts). Also I find easier QT because I have experience with C++ but no with Objective C and I think that are more experienced C++ developers than Objective C.
To clarify and answer some questions:
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 developer.symbian.org)
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.
teknolog - thanks for providing that clarification, especially on seperate install versus being included.
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.
Rafe wrote:
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.
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.
Thanks for that info svdwal. I wonder if this issue has been fixed on the newer devices. Qt for Symbian is targeted at S60 3.1 and upwards so could still be an issue.
I agree size is less of an issue, but smaller is always better if you're doing something OTA (e.g. Ovi Store).
Rafe wrote:I agree size is less of an issue, but smaller is always better if you're doing something OTA (e.g. Ovi Store).
Agreed. Being complacent about size = bloat.
See also Simon Judge's blog post on this subject:
http://mobilephonedevelopment.com/archives/909