Qt vs Symbian C++



  • Hi there,

    Assume that one would want to develop only for Symbian devices, which use cases would favor development in Qt and which ones for Symbian C++?



  • I would say that developing for "Symbian only" using Qt is buying you future benefits, since you never know when you'll be asked for that lovely application you have now running only in Symbian to be available for, let's say, Linux.

    Si for me, if both tools (Symbian C++ and Qt) will involve the same learning and/or developing effort the equation is clear: I'll use Qt


  • Moderators

    I agree with pablojr. The effort put into developing with Qt potentially has various additional benefits simply due to the cross-platform nature of the toolkit. Since Nokia's acquisition of TrollTech, it looks like Qt is going to continue to play more of a stronger role in Mobile Development. It doesn't look as if its future is dim at all.



  • What do you think would happen to Symbian C++, would it continue to exist? Would Qt complement it in someway or completely replace Symbian C++ ?



  • I finde Symbian C++ to be a lot less straightforward than Qt. I can see Qt taking a fair amount of developers away from Symbian C++, but I don't think it will replace it.



  • As far as c++ application development is concerned Qt will replace symbian c++. As others pointed out, it is much more easier and is cross platform. With Symbian 4, the S60 avkon framework will not be supported and Qt will be the only choice for building guis for c++ applications. For Symbian c++ apis other than GUI, you may mix them with Qt code if needed. But that will be rare, with Qt mobility available.



  • Remaining use cases for Symbian C++:

    1. If you need a rock-solid stable background server (because Qt doesn't have any mechanism for handling out-of-memory issues yet)
    2. Accessing platform APIs which aren't available via Qt Mobility.
    3. Supporting old devices (there are still some out there that Qt won't run on, particularly in poorer countries)

    That's about all I can think of.

    Basically, if you can use Qt then do!

    Mark (Kernel & Base Technology Manager at the Symbian Foundation)



  • Thanks Mark and Jaykrishnan,

    If an app is targeted for the current crop of Symbian devices and requires accessing platform APIs, Symbian C++ can be used. However, if the app is heavy on UI, Qt would be a better option. That is the best I could summarize it.



  • I'd go further than that - if there is ANY UI, and you can use Qt, then do use Qt. Don't write a new UI in Symbian C++ unless you absolutely have to.



  • Just in - there is a firmware update for the N900 and it contains the Qt 4.6.2 libraries. So no need to bundle the core with the app :-)

    However, that still leaves this question open - how will Qt help provide rich UI apps to the existing millions of Symbian devices ?

    One may say, by adding the Qt libraries to the app, but that would make the size of the app around 8 MB + which is not so good with devices with limited memory like the N97.

    Qt is not so much backward compatible, it's applicability to future devices seems assured.



  • Have you checked Symbian smart installer for Qt ? With this, there is no need to bundle Qt with your app. At the installation time, the smart installer downloads and install Qt if Qt is not already installed on the phone. I haven't used it yet. So I don't know how good it works. If anybody have used it, it will be good if they can share their experience



  • I have read about the smart installer, it was at beta 2.0. Whether one bundles the Qt libraries with app code or uses the smart installer, eventually the libraries will be installed on the phone memory. The current footprint is around 8 MB, which on phones like the N97, is quite a lot.

    I have tried installing the qt_installer.sis ( this is available in the latest beta SDK) and it always installs in the C: drive, not the mass memory.

    I think in future iterations of Qt, it is important for the libraries to be able to run on mass memory, the end user should have this choice.



  • bq. I think in future iterations of Qt, it is important for the libraries to be able to run on mass memory, the end user should have this choice.

    It is not that easy as You say it is. Please correct me if I’m wrong but usually the devices mass memory is some kind of Flash NAND, in witch case every code stored in this memory needs to be copied in to the devices RAM memory. On the other hand the devices C: drive is usually some kind of Flash NOR, witch can store XIP code (eXecute in Place), this cuts the start-up time substantially because there is no need to copy the code in to RAM.



  • To be honest, I have no idea about the differences between how code executes on C:\ vs on the mass memory. But there are so many apps, specifically those written in Symbian C++, which install on either memory just as easily.

    Qt, on the other hand, currently does not do that. It somehow installs only on the C:\ drive.

    I would hope and expect, in the future, that installing Qt apps on either of these memories be possible.



  • [quote author="varunnarula" date="1275402178"]I would hope and expect, in the future, that installing Qt apps on either of these memories be possible. [/quote]

    You can easily install Qt applications at mass memory. But Qt libraries should be better installed at c:\ (even if they will work at mass memory) because of performance issues.



  • I have tried installing the qt_installer.sis which comes with the (beta) Qt SDK and during installation, the option is provided, but I noticed that all the library components installed on the C: drive.

    Have you tried installing any Qt application (bundled with the Qt libraries) on the mass memory. Do let me know, this is something I want to try out.



  • Have not tried apps bundled with qt libs, but installing at first qt libs (on main memory) and at second qt app (on SD-card) worked well.



  • [quote author="kkrzewniak" date="1275206164"]
    It is not that easy as You say it is. Please correct me if I’m wrong but usually the devices mass memory is some kind of Flash NAND, in witch case every code stored in this memory needs to be copied in to the devices RAM memory. On the other hand the devices C: drive is usually some kind of Flash NOR, witch can store XIP code (eXecute in Place), this cuts the start-up time substantially because there is no need to copy the code in to RAM.
    [/quote]
    No, I'm afraid you are wrong. For many years now the C: drive and the Z: drive (which is where the ROM runs from) have been on NAND flash and are copied to RAM before they run. Typically NOR flash is too slow for modern processors and too expensive compared to NAND + more RAM.

    A good reason not to store the Qt libs in mass memory is because on some devices that might be a removable card and then any apps installed to C: that needed the libs wouldn't work when the card was removed.

    The proper solution to this problem is for Nokia to stop creating devices with too little space on C:!



  • bq. The proper solution to this problem is for Nokia to stop creating devices with too little space on C:!

    That is exactly the problem. 128 MB will just not cut it. At the very least, 256 MB is required. The N900 has some virtual memory, any idea if something similar can be done on Symbian ?

    Take the N97 for example, and with Maps, Quickoffice, Qt and browser cache, the memory quickly fills up. With virtual memory, this problem could be solved.



  • No, you're confusing RAM and Flash. Symbian does have virtual memory in the form of demand paging and specifically Writable Data Paging in Symbian^3. That will mean more free RAM but it doesn't help with the amount of space on C: (in fact it could make it worse because that data has to be paged out to flash somewhere!).



  • [quote author="varunnarula" date="1275576380"]I have tried installing the qt_installer.sis which comes with the (beta) Qt SDK and during installation, the option is provided, but I noticed that all the library components installed on the C: drive.

    Have you tried installing any Qt application (bundled with the Qt libraries) on the mass memory. Do let me know, this is something I want to try out.[/quote]

    There was an issue with qt_installer.sis and it need to be installed on c: only. It was said to be fixed in the newer versions.

    However, apart from this you can install any Qt Application in the mass memory.



  • [quote author="varunnarula" date="1276181289"]bq. The proper solution to this problem is for Nokia to stop creating devices with too little space on C:!

    That is exactly the problem. 128 MB will just not cut it. At the very least, 256 MB is required. The N900 has some virtual memory, any idea if something similar can be done on Symbian ?

    Take the N97 for example, and with Maps, Quickoffice, Qt and browser cache, the memory quickly fills up. With virtual memory, this problem could be solved.

    [/quote]

    I do agree N97 has memory issues. But I think most new devices will handle these issues now.



  • The qt_installer.sis was from the beta 1 of the Qt SDK released recently. Have yet to try the one from the latest beta, I believe it is 2.0.



  • I hope the N97 is the last phone with 128 MB :-)



  • [quote author="QtK" date="1276271405"]
    There was an issue with qt_installer.sis and it need to be installed on c: only. It was said to be fixed in the newer versions. [/quote]

    The reason we force Qt on C: is because otherwise applications startup can take several seconds - we're talking 15 seconds for example. That is simply not acceptable for an end user.

    Now, the reason it is slow to load, is because of an overzealous security check on Symbian, where they will re-read and calculate a CRC/MD5/checksum of a library loaded by an app too many times (imagine it's re-reading QtGui 4-5 times for an app startup, just to make sure it's not been tampered with). This check only kicks in for libraries installed on mass memory, so if it's on C this doesn't even happen.

    So, basically - is it possible to have Qt installed somewhere else than C, yes. Is it recommended, no. And that's why the qt_installer.sis is hardcoded to put it on C.



  • [quote author="snowpong" date="1284454969"][quote author="QtK" date="1276271405"]
    There was an issue with qt_installer.sis and it need to be installed on c: only. It was said to be fixed in the newer versions. [/quote]

    The reason we force Qt on C: is because otherwise applications startup can take several seconds - we're talking 15 seconds for example. That is simply not acceptable for an end user.

    Now, the reason it is slow to load, is because of an overzealous security check on Symbian, where they will re-read and calculate a CRC/MD5/checksum of a library loaded by an app too many times (imagine it's re-reading QtGui 4-5 times for an app startup, just to make sure it's not been tampered with). This check only kicks in for libraries installed on mass memory, so if it's on C this doesn't even happen.

    So, basically - is it possible to have Qt installed somewhere else than C, yes. Is it recommended, no. And that's why the qt_installer.sis is hardcoded to put it on C.[/quote]

    Thank you for making it clear.

    Does Nokia smart installer do the same. Because at times you have only a few MB left in C: on your device.



  • [quote author="QtK" date="1284456470"]
    Thank you for making it clear.

    Does Nokia smart installer do the same. Because at times you have only a few MB left in C: on your device.
    [/quote]

    The Smart Installer will force it onto C as well, and fail gracefully if there is not enough space.



  • [quote author="snowpong" date="1284456669"][quote author="QtK" date="1284456470"]
    Thank you for making it clear.

    Does Nokia smart installer do the same. Because at times you have only a few MB left in C: on your device.
    [/quote]

    The Smart Installer will force it onto C as well, and fail gracefully if there is not enough space.

    [/quote]

    Will this delay in launching be observed in anyway, if an end-user application has some libraries and are not placed in C:. Or this affects only the Qt runtime libraries.



  • [quote author="QtK" date="1284457056"]Will this delay in launching be observed in anyway, if an end-user application has some libraries and are not placed in C:. Or this affects only the Qt runtime libraries.
    [/quote]

    Typically no. It's a special case. You'll experience it if:

    Your library is big (2-5megs for example)

    You have lots of plugins that link back to your library again

    So in general, don't worry. If you have a library with your app it's not gonna hit you in most cases.



  • [quote author="snowpong" date="1284457553"][quote author="QtK" date="1284457056"]Will this delay in launching be observed in anyway, if an end-user application has some libraries and are not placed in C:. Or this affects only the Qt runtime libraries.
    [/quote]

    Typically no. It's a special case. You'll experience it if:

    Your library is big (2-5megs for example)

    You have lots of plugins that link back to your library again

    So in general, don't worry. If you have a library with your app it's not gonna hit you in most cases.

    [/quote]

    Thank you for the clarification.



  • I read on forum nokia discussion forums that the smart installer is currently useful only for deploying Qt apps to a very few Symbian devices. The reason cited was lack of space on c drive on most of the current devices. Is this true ? I have one project I'am planning to do in Qt. If the above is true I have to revert back to native Symbian api.



  • [quote author="Jayakrishnan.M" date="1284624241"]
    I read on forum nokia discussion forums that the smart installer is currently useful only for deploying Qt apps to a very few Symbian devices. The reason cited was lack of space on c drive on most of the current devices. Is this true ? I have one project I'am planning to do in Qt. If the above is true I have to revert back to native Symbian api.[/quote]

    Smart Installer too installs Qt libraries to C:, so if there is not enough space it cannot get installed.



  • But then going forward more devices are expected to be launched with Qt pre-installed.



  • Here is the "best documented list":http://www.forum.nokia.com/Distribute/Packaging_and_signing.xhtml#article1_a I could find of the current devices OVI / Smart Installer likes.



  • [quote author="snowpong" date="1284630014"]Here is the "best documented list":http://www.forum.nokia.com/Distribute/Packaging_and_signing.xhtml#article1_a I could find of the current devices OVI / Smart Installer likes.[/quote]

    Thanks for the link.



  • There is a new SmartInstaller v1.1 by the way.
    http://info.publish.ovi.com/?p=596
    Mandatory as of today but was released last week.

    Some stuff may have changed with regards to this topic.



  • Thanks for the update

    But - why can't they put a date on news releases like this? They say "Starting today, the new Nokia Smart Installer v1.1 is now mandatory for all Qt- based Symbian apps submitted to Ovi Publish" yet there is no date anywhere...



  • It says it was released on the 24th in the wiki that page links to. Unless you meant when it became mandatory. Date of article was 2nd of December I think. I remember seeing the date before but now that I look, it's not there :O

    By the way, just after this announcement one of my smart installer apps passed QA. So it's only for new submissions.



  • But Nokia have stated that all Qt runtimes will be backwards compatible with Qt4.6.3. So not really a mess. The only things that aren't back compatible are the 'labs' that you shouldn't be using in production app anyway.

    Also, they are fixing the Smart Installer thing. You won't have to say it may download up to 13MB of additional files anymore.

    The only markets I wasn't able to distribute apps using SmartInstaller were Mainland China (without licencing partnership) and Korea (no idea?). But I don't think those had anything to do with Qt or Symbian C++.
    I'm not sure why an operator would restrict Qt. Makes no sense really. Surely the customers would debrand their device or yell at their operator and not come back.



  • Well as they are removing the "download up to 13MB of additional files" restriction, maybe they are also making the Qt download come from Ovi Store.

    What's the domain that Ovi Store uses? There's no reason they couldn't host Qt Installer on there.


Log in to reply
 

Looks like your connection to Qt Forum was lost, please wait while we try to reconnect.