Android and WebOS took the top-down approach, and made a streamlined development process heavily based on existing technologies (the Java language in the case of Android and web related tech in WebOS). This allowed for fast application development, leveraging existing developer resources and knowledge for the particular platforms, at the expense of making the jump to native code a bit more difficult or the realm of hackers. The very important lesson here was also that they very successfully hid their Linux roots, not making the Linux heritage a drawback (to the point that very few people will actually regard Android as a Linux mobile platform).
However, there was another camp, the bottom-up one, with Maemo/MeeGo and LiMo as the more prominent representatives, which promised most of the desktop technologies in a mobile environment. The advantage should have been the obvious 'just apply whatever technology you know', but in reality, this has slightly backfired up until now. While they proved to be a great basis to hack on and immediately took the hearts of many Linux diehards, there was a steep learning curve that was unappealing to many developers with little Linux background. For example, Maemo's Scratchbox environment and lack of a traditional IDE/SDK are cited being the points where many hobbyist devs gave up on these platforms. In retrospect, these factors sentenced this group of platforms to be seen in the eyes of mainstream end-users as a land of ports and emulators, with the occasional community gem application in the sea of working-but-not-quite-there-yet apps.
Returning to the title - how does this Nokia Qt SDK change any of this, especially with regard to the latter group ? The key is to understand that this is not a classic platform SDK. Let's see what exactly is happening here:
- While the technologies present in the package (Qt, Qt Creator and the cross-compiling tools) are not new by a long shot, this is the first time they start to appear as a cohesive, focused way of creating applications A-Z style.
- A classic IDE-style approach is employed that will appeal to many devs used to such tools, while keeping the power of console and functionality of other existing custom tools.
- It's a toolkit SDK, not a platform SDK. This in turn allows access to the vast array of various platforms and devices. Currently the focus is obviously on Nokia's Symbian and Maemo platforms, but here's where Qt really shines - you're not learning to code Symbian or code Android stuff. The Qt skills you learn are actually just as applicable to the desktop, whether that be Windows, Linux or Mac.
- Multiplatform authoring tools. Currently Windows and Linux, but my guess is that a Mac version could be produced fairly quickly if serious interest appears.
- While Qt provides a level of abstraction, the underpinning platform is not being crippled, and thus applications are being able to take full advantage of it.
As you can see, the goal seems to be to provide a streamlined way of producing modern applications for a range of platforms, while avoiding the dumbing down of platforms to make them fit into a particular mold. I hear you say, okay, so you think this Qt SDK thing will take over the world, right ? Well, while not excluding the possibility, there are a few obstacles that the Qt SDK needs to address before going for world domination in the mobile app development arena:
- Unified (declarative) UI. Cool compilers and cool IDEs do not necessarily mean cool apps. It is paramount that a unified API (based in some form on the Declarative UI of Qt4.7) exists for widgets and app UIs. If each app will have to have it's UI rewritten due do Orbit/DUI/vendor specific/desktop widget issues, that will significantly reduce the appeal of Qt and proliferate curse-of-plenty problems.
- Do a final release in a reasonable time-frame. Today we have seen a beta to whet our appetite, but the other tools and platforms have a serious headstart. Winning Symbian folks over is a good start (the inclusion of Qt libs on the new Nokia N8 will kickstart this process nicely), but the real race is to get on the radar of developers currently under heavy influence by Android and the iPhone.
- Go for Android. This topic alone is grounds for another blog post. Technically, it's known to be possible, there is even is a community level Qt for Android port floating around. I will not go in the business/technical reasoning of the dangers/wins of such a move (maybe in another post), but I feel that it needs to be kept at least as an option, an ace up the Qt sleeve if you wish.
- Add python support. The use of Python Qt bindings has a long and successful history. Python is easy, and on modern hardware, a Python and Qt combination is much less a drag than it ever was on embedded platforms, as proven by PyQt and PySide on Maemo. C++ is not everyone's cup of tea, and Python is an excellent complementary language for it, while maintaining a solid Qt based 'upgrade' path should developers need it. Doing this without switching SDKs or IDEs would go a long way of making Qt even more appealing to new developers.
If you want to take this new SDK for a spin, you can do it here.
Posts
