Comparing Mobile OS SDK availability by platform

Coming back from Nokia World in London earlier this week (thanks to Nokia Developer for inviting me), I've been thinking about the SDK availability for different mobile operating systems given a specific Desktop platform. While leaving out all the other criteria (openness, libreness, licensing, UX, device capabilities, programming languages, toolkits, data formats, annual costs for the SDK/developer account, store rules, target audience, revenue splitting, advertising/in-app purchase options, coolness, etc..) developers can choose their mobile OS by, I want to highlight a specific aspect: The availability of an SDK for a given Desktop operating system.

First up, I'm only talking about native apps here (with "native" being anything that's not just some HTML+JS zipped up or served via the web, i.e. native usually means you need to have some form of compiler, even if it targets a VM). If you are into "web apps", chances are that you don't need an SDK to get started (even though one might help). I'll look at iOS and Android (because these are the strong mainstream OSes today), Maemo/MeeGo (because it's my platform of choice right now), Symbian (because I'm targeting it too with Qt) and WP7 (because that's what MS and Nokia want to succeed). When I write "MeeGo" I mean MeeGo 1.2 Harmattan, which technically is more like a "Maemo 6". Think "the OS that the N9 runs". I have a bit of experience with Android development, no experience at all with iOS or WP7, some experience with Symbian (through Qt) and arguably lots of experience with Maemo/MeeGo (yay!).

Why is that important? First up, if you are a Linux or OS X user, chances are that you don't have a Windows installation, and installing Windows will cost you money (for the Windows license), time (because you have to set it up) and space (because you have to dedicate a partition/VM image for it). If you don't have Apple hardware, getting an OS X installation means purchasing Apple hardware (ignoring Hackintoshes here), which is again costly. At least you would need to purchase OS X and dedicate a partition/VM for it, plus the time it needs to set it up.

Why OS X and Windows? As far as I know, if you want to develop for iOS, you have to use XCode, and that is only available on Mac OS X. Similarly, if you want to develop for WP7, you have to use the Windows Phone SDK, which is only available on Windows (>= Vista according to the website, so your XP install might not help there).

Now, let's look at Android, MeeGo and Symbian. Android's SDK is available for Windows, Linux (x86 and amd64) and Mac OS X. You can compile your apps on all these platforms (using your system's javac + tooling provided by the SDK). For C/C++ Android apps, the NDK is also available for all three platforms. For Qt-based OSes (Symbian and Maemo/MeeGo), the Qt SDK itself is available for Windows, Linux (x86 and amd64) and Mac OS X (64-bit). Using the Remote Compiler (which uses compilers set up on a server farm at Nokia, and you need a Nokia Developer account to use it) you can compile Symbian binaries on OS X, Linux and Windows, although the locally-installable compilers for Symbian are only available on Windows (at least that was the case 6 months ago). For Maemo and MeeGo, cross-compilers exist natively for all supported platforms of the Qt SDK, so without using Remote Compiler, you can build and package your Qt apps for MeeGo on Windows, Linux (x86 and amd64) and OS X.

Now, people can argue that one can set up dual-boot or virtual machines to support all OSes, but that's not the point. The point is that if the SDK is available on all Desktop platforms (note that this is not the same as SDK targetting all mobile platforms), developers can retain their choice of Desktop OS on which they develop on, and are not forced to use OS X or Windows for development of apps for the corresponding mobile platform (I also understand the reason why these companies only provide the SDK for their own Desktop platform, but that is not a good reason from a developer's point of view).

I hope that the Qt SDK will continue to support Windows, Mac OS and Linux for any mobile target platforms that it supports - be it ones named after winds or not - so developers have a choice of development platform.

In other news, gPodder 2.950.15 has been uploaded to Nokia Store (still waiting in QA) which fixes video playback and streaming, so grab the update on your N950/N9 when it becomes available :)

qw The Game 1.5.1 is here - for MeeGo and Symbian

Control the white ship to fill areas.

Last December, I started to work on a new game: qw ("cuvée"), an area filling game similar to Qix. Since the tech demo has been released, I've been working on a fancy QML menu, a balanced scoring system, nice rendering effects for enemies and the player's trail and obviously some more levels, which results in this new release, version 1.5.1, with 13 high-definition images that are waiting for you to get their colors back.

The game is now available from Ovi Store for N950 and N9 users, and also for Symbian devices - the advantage of the MeeGo version being that it has higher-resolution artwork (it fully utilizes the higher screen resolution) and sound effects (for some reason Qt Mobility's QML SoundEffect has its problems on Symbian). Both versions use the feedback motor of the device for feedback when you draw, fill or die.

Here's a gameplay video of the first 3 levels, so you can get a feeling of how the game plays:

That Rabbit Game 1.2 is now available for Maemo 5

I've blogged about it already, and even showed some code during an Interview at Nokia World, but there have not been any releases of That Rabbit Game so far, mostly due to Ovi Store QA not understanding what Optification means and requesting that the version number of the application appears somewhere in the app UI (after 15 days in QA). I've made the requested changes, added scoring and pushed new releases (of version 1.2) for both Symbian and Maemo 5 to Ovi QA.

Until the game gets published on Ovi, I decided to release packages on the website so you can download and enjoy the game right away - and maybe even provide some feedback. Please don't mirror/redistribute the packages, but link directly to the website. Download That Rabbit Game for Maemo 5!

Controls are via accelerometer (to tilt the rabbit head left/right) and via touchscreen (tap to flap your wings - the longer you tap, the harder the wings flap). The goal is to lose 10 coins in 90 seconds by getting shot 10 times. After that, the next goal is to lose the 10 coins in as little time as possible. Yes, you control the rabbit head, and not the crosshairs.

Updates and changes will be announced via @thatrabbitgame on Twitter, so follow it and tell your friends. Enjoy!

The Qt promise and what Maemo 5 needs

(tl;dr: Nokia should provide updated Qt packages as official SSU for Maemo 5.) Before I start, here are some facts (correct me if I'm wrong):

• The N900 runs the Maemo 5 operating system
• Maemo 5 received some updates (the latest one being PR1.3)
• We don't really expect PR1.4 to come out any time soon, if at all
• The MeeGo Handset images from meego.com are inferior to Maemo 5 and not a replacement (and never will be)
• The MeeGo operating system on the first Nokia MeeGo handset will have a proprietary UX and proprietary apps, and won't be available for the N900

In summary, it means: We are stuck with Maemo 5 on the N900. And that is a good thing! Lots of useful apps, a helpful community (if you subtract the trolls) and a polished OS. Sure, there's room for improvement, and lots of open bugs that should be fixed, but that's another issue (which will ideally be solved by open sourcing closed components with bugs that Nokia isn't interested in fixing anymore and by the Community SSU). This one is about Qt.

Two days ago, an e-mail was sent to maemo-community, proposing a "community service pack", which basically is a big pile of workarounds. Read my response for some initial thoughts.

When Qt arrived on Maemo 5, the promise was two-fold:

• Write your apps in Qt and you're ready for MeeGo (apps written now will run on the platform released in the future)
• Maemo 5 gets Qt support, so MeeGo apps will run on the N900 (apps written in the future will run on the platform released now)

It turns out that the first one will probably hold true (surely with QML, maybe even with QWidget), while the second one is doubtful, as Maemo 5 has only got Qt 4.7.0 through the official channels (PR1.3), with no real official update in sight. If you use QML, use QtQuickCompat as workaround ("Qt Qml plugin that reregisters all “Qt 4.7” types in the “QtQuick 1.0” namespace … useful if you’re forced to stay with 4.7.0 (e.g. on N900), but still want to use the new namespace.").

There is also a real bug (yes, a bug!) in Qt 4.7.0 on the N900, and the fix isn't released as update - it's a new package: libqt4-bearer-hotfix ("This is a hotfix for the broken ICD package in Qt 4.7.0. It can be removed once Qt mobility 1.1 is released."). Now, the proposed "Community service pack" would combine all these fixes into a single dependendable metapackage (yes, a new one). It becomes the "Unbreak my Qt" feature that every app developer has to depend on and specify in the packaging.

This is wrong! No developer targetting MeeGo who has not heard about Maemo 5 will go through all those ugly workarounds and spend a week fixing things up for Maemo 5 just so that the app works. Now imagine what would happen if the first MeeGo device also introduces such kludges once it falls out of its support life cycle. Or what if the problems on Symbian are similar, and developers have to special-case things there. Not only for Symbian^3, but also for S60v5? Fragmentation.

How to avoid fragmentation? Simple: Provide Qt as a "feature" with a quicker release cycle that can be updated every month if need be. Provide Qt updates also for operating systems that don't get updates for the OS anymore. Here's my proposal:

• Provide SSU updates for Maemo 5 for Qt (and Qt Mobility) through official channels (that's the important part here!)
• A new Qt (and Qt Mobility) release should be available on all platforms (Maemo 5, S60v5, Symbian^3, MeeGo) at the same time through official (end-user approved) channels
• Apps targetting stores and repositories (Maemo Extras, Ovi Store, MeeGo Apps/Downloads) should be able to depend on the latest Qt (and Qt Mobility) version

Without that, you'll get fragmentation similar to Android: The 1.5, 1.6, 2.1 versions are similar to Qt 4.6, Qt 4.7.0 and Qt 4.7.1 (for example). Again, you don't need to update the OS, just update the framework - through official channels!

Qt: Write once, #ifdef everywhere?

Despite what the title of this post might suggest, I really like Qt. But as a developer, I also know that "write once, run everywhere" isn't realistic without writing some special-cased platform-specific code. Qt does take care of many platform-specific things, and I think it's the closest you can get to "write once, run everywhere" right now.

This post should serve two purposes: To provide a real-world example of what needs to be done in the code for the app to work on both Maemo 5 and Symbian^3 (with example code), and to get suggestions on what parts I could rewrite in a more platform-agnostic manner with existing APIs (so please comment if you are in the know!).

Here's the story: In early September, I've rewritten my game "That Rabbit Game" to use QGraphicsView on the N900, and in the last weeks, I've ported it to Symbian^3. I use the macro Q_OS_SYMBIAN to check for Symbian and Q_WS_MAEMO_5 to check for Fremantle. Here's the current main menu on a N900 and N8 (different screen resolutions and aspect ratios):

Qt modules: In the qmake project file, I can use linux-g++-maemo5 to add Maemo-specific configuration, and symbian for Symbian-specific settings. I use D-Bus module on Maemo, but obviously not on Symbian, so my project file contains something like this:

linux-g++-maemo5 {
    QT += dbus
}

This is nice, because I only have to maintain one project file, and the block structure is very readable (and I can even use different Qt submodules for each platform).

Screen orientation: Symbian has auto-rotation for Qt apps by default, and Maemo 5 has landscape-only mode by default. For my game, portrait mode does not make sense, so I have to request landscape-only on Symbian (similarly, if I want auto-rotation everywhere, I have to request it on Maemo 5 and do nothing in Symbian). For this specific case, I need some libs in Symbian, so I add this to the project file:

symbian {
    LIBS += -lcone -leikcore -lavkon
}

I also need to add this to the top of my main source file:

#ifdef Q_OS_SYMBIAN
#include <AknAppUi.h>
#endif

And finally, I have to copy'n'paste a code block into my main() function before I create the first window:

#ifdef Q_OS_SYMBIAN
CAknAppUi* appUi = dynamic_cast<CAknAppUi*> (CEikonEnv::Static()->AppUi());
TRAPD(error,
if (appUi) {
    // Lock application orientation into landscape
    appUi->SetOrientationL(CAknAppUi::EAppUiOrientationLandscape);
}
);
#endif

It would be nice if Qt (or Qt Mobility?) has some generic API for this, where I just need to do something along the lines of QRotation::setMode(QRotation::LandscapeOnly); and let it take care of the platform-specific stuff.

Accelerated QGraphicsView: On Symbian^3, QGraphicsView is automatically accelerated via OpenVG (I think), but on Maemo 5, it can use OpenGL for this (but does not by default), so in the code where I create my QGraphicsView, I have to have this at the top:

#ifdef Q_WS_MAEMO_5
#   include <QGLWidget>
#endif

And then somewhere down that file where I create the QGraphicsView, this code goes there:

#ifdef Q_WS_MAEMO_5
    QGLWidget *glw = new QGLWidget(QGLFormat(QGL::DoubleBuffer));
    view->setViewport(glw);
#endif

It's not that difficult, and is already cross-platform (on platforms where OpenGL is available), but maybe QGraphicsView can be OpenGL-accelerated on Maemo 5 by default. Maybe there is some non-obvious side effect that using an OpenGL viewport has that I'm not aware of, and that's why one has to do it manually.

Accelerometer readings: This might actually be a bug in Qt Mobility. For my game, I have to read the accelerometer's Y axis on Symbian, and its X axis on Maemo to determine the rotation for the same holding position of the device, so there's another platform-specific #ifdef there. Again, this will hopefully be fixed in a future release of Qt Mobility, and will most likely be fixed for MeeGo as well.

Task switcher: It's customary on Maemo to have a task switcher button in the upper left corner. There's no platform-agnostic way of going to the task switcher, so I needed to special-case it for Maemo 5, and have not bothered implementing it on Symbian^3 (suggestions welcome!). First, I need to include D-Bus headers for this (I've already mentioned how to request the D-Bus module in the qmake project file above) :

#if defined(Q_WS_MAEMO_5)
#   include <QDBusConnection>
#   include <QDBusMessage>
#endif

When I'm in the handler code where I need to do the actual task switching, I can utilize it to activate Maemo 5's task switcher:

#if defined(Q_WS_MAEMO_5)
        QDBusConnection c = QDBusConnection::sessionBus();
        QDBusMessage m = QDBusMessage::createSignal("/", "com.nokia.hildon_desktop", "exit_app_view");
        c.send(m);
#endif

This is very much Maemo 5-specific, and will very likely not work on MeeGo Harmattan. Again, here it would be nice to have a cross-platform way of doing window management (in Qt or Qt Mobility?). I can imagine this being useful not only on handsets, but also on netbooks and tablets (from a MeeGo PoV). Again, trying to come up with pseudo-APIs here, QWindowManager::showTaskSwitcher(); could be a nice way to handle this in a cross-platform way, hiding platform-specific implementations. From what I've seen of MeeGo Touch, activating the task switcher there simply iconifies the window on the Desktop, so maybe if I would iconify my main window, it should activate the task switcher on Maemo 5 and Symbian. It does not work on Maemo 5 right now, though, and I haven't tested it on Symbian.

Screen resolution: This was (thanks to QGraphicsView) less of a problem than I thought it would be. Symbian^3 (or at least the N8) uses 640x360 as its resolution, and Maemo 5 uses 800x480. Maybe the MeeGo Harmattan device will use yet another resolution. I still configure my QGraphicsScene object manually via #ifdefs to get a good resolution, but the code could just measure the resolution and configure the scene as well. Here's what I use:

#if defined(Q_WS_MAEMO_5)
    setSceneRect(0, 0, 800, 480);
#elif defined(Q_OS_SYMBIAN)
    setSceneRect(0, 0, 640, 360);
#endif

I then use the sceneRect() of my scene to calculate a scale factor for all contents and call setScale() on all root items of the scene to scale the contents to the current screen size. You might have to take care of different aspect ratios on different devices, too - but it was unproblematic for my use case (the game) this time.