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 :)

Maemo App Development - One Year Ago

I just realized that one year ago, I was giving a talk about Maemo Development at the Metalab here in Vienna. Back in January 2010, things were still very much different from today:

• Scratchbox was the SDK - Linux only, VMs for everything else
• No proper IDEs for Hildon development (there was Eclipse integration, but I never used it)
• Qt still was "the new stuff that's coming up" for Maemo development
• Mer was still something to look forward to
• MeeGo didn't exist - Maemo 6 was the future ;)
• MADDE was in Technology Preview state - not widely used
• Direct UI (now MeeGo Touch) was thought to be the future toolkit
• Qt 4.6 was just released in December - no QML in Qt yet

It turns out that we are in a much better position now, we've got a nice cross-platform IDE (Qt Creator), a proper SDK (Qt SDK) that works on Windows and OS X the same as on Linux and the "low-level" issues (optification, packaging, ...) are handled by Qt Creator mostly.

Today, the issues are different - I'm complaining about Qt Creator (from the Qt SDK 1.1 Preview) crashing a lot in QML design mode, I can deploy my apps to Symbian devices without much effort (didn't think I would ever do that) - even though there's no proper toolchain for Linux or OS X (Remote Compiler doesn't count). The Qt Quick Components are still not released, even though I'd love to create some great apps with them. And most people forget in the N9 rumor jungle that we have still got the best Linux-based mobile OS (with Linux userland) that exists in an actual product that you can buy right now (that's Maemo 5 on the N900 if you didn't get that hint..). Just like Duke Nukem Forever, a MeeGo handset will be announced and released eventually - give it some time.

Back to the "Qt Creator shouldn't crash when editing QML" developer story: We're not there yet, but comparing the current state with the state one year ago, that's some progress right there! Looking forward to those bits falling into place in the upcoming months.

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!

SSH agent forwarding in Scratchbox

I usually have the Maemo SDK running inside a VM - either completely remote or on the same machine (so I can have a 32-bit minimal Debian install containing Scratchbox independent of the host system). I can then SSH into the development VM from my working machine using public key authentication and the SSH agent. I also have agent forwarding set up, so that I can SSH from the SDK machine directly to the N900 (to deploy binaries and .debs) or to some server requiring SSH access (e.g. drop.maemo.org) without having to generate lots of keys and distributing the key to all kinds of different machines.

Using -A (or ForwardAgent yes in .ssh/config) when SSHing into the SDK machine makes it possible to connect to other machines from it, utilizing your SSH key. This sadly does not work when starting scratchbox, because it opens a new environment, and the $SSH_AUTH_SOCK environment variable is lost. To fix this, I simply write the contents of this variable into a file accessible from Scratchbox and then export this variable in the Scratchbox login script. I usually also have a symlink in $HOME pointing to the SDK $HOME:

ln -s /scratchbox/users/$USER/home/$USER ~/sdk

With this in place, I can now edit the "normal" user's login script by adding the following line at the end of .bashrc:

echo $SSH_AUTH_SOCK >~/sdk/.ssh_auth_sock

Scratchbox has its own login script (also called .bashrc, but sitting in the Scratchbox home folder), so we edit this and add the following line:

export SSH_AUTH_SOCK=`cat .ssh_auth_sock`

After this, logout of Scratchbox, logout of the SSH session and then connect again with SSH forwarding:

ssh user@maemosdk -A
scratchbox
ssh-add -l

The last command should display the fingerprint of your SSH key. You can now connect to remote hosts from within your Scratchbox session while your SSH key still resides only on your local machine, loaded into the SSH agent.

App updates: gPodder 2.4 and MaePad 1.5

This week, it's once again time to update two of the more prominent apps in my collection: gPodder 2.4 "The Pants Alternative" for both Diablo and Fremantle and MaePad 1.5 "Productive" for Fremantle.

With the installation of PR1.2 on the autobuilder, MaePad can once again be built on it, so I've resumed uploading of MaePad releases to Maemo.org.

So, what's in it for you? Let's start with gPodder:

• Progress bar for loading episodes (and optimized episode list loading)
• "All episodes" view is not grouped per-podcast anymore (all episodes are now sorted descending by date)
• Faster download resuming on application start (with progress dialog)
• Automatic clean-up of finished downloads
• Simplified layout of progress indicator dialogs (e.g. deleting episodes, unsubscribing from podcasts)

And now for your favourite productivity tool, the MaePad:

• "w" in the checklist/sketch view now saves the database
• Fullscreen mode of checklists uses portrait mode (for shopping use, etc..)
• Node type displayed in overview (there's a themeing issue here with the highlights and the secondary text color.. suggestions welcome)

Now it's your turn: Please test the new packages and then vote for the packages here: MaePad QA page and gPodder QA page. Any bugs that you will find should be reported here: new bug against gPodder and MæPad t.m.o thread.

The PR1.2 SDK on the autobuilder adds a dependency on a newer Hildon version that cannot be fulfilled in earlier firmware versions, so I'll build a package compatible with pre-PR1.2 firmware soon and publish the package on the MaePad homepage for manual installation during this transition period until PR1.2 becomes available for end users.

HOWTO: Stable Xephyr on Ubuntu 9.04 for Fremantle SDK

As stated in the Fremantle SDK Installation Notes, Xephyr on Ubuntu 9.04 crashes when clicking on a text field in the Fremantle Beta SDK. It also says that the Intrepid (Ubuntu 8.10) version works better. Here is how you can compile and install Intrepid's Xephyr version:

sudo apt-get build-dep xserver-xephyr
sudo apt-get install build-essential devscripts
dget http://at.archive.ubuntu.com/ubuntu/pool/main/x/xorg-server/xorg-server_1.5.2-2ubuntu3.dsc
dpkg-source -x xorg-server_1.5.2-2ubuntu3.dsc
cd xorg-server-1.5.2/
debuild
cd ..
sudo dpkg -i xserver-xephyr_1.5.2-2ubuntu3_i386.deb
Xephyr :2 -host-cursor -screen 800x480x16 -dpi 96 -ac &

Now you can start the Fremantle Beta SDK and run it without crashing all the time :) You can delete the rest of the .deb packages created - they are not needed for Xephyr. If you want to go back (well... "forward" really) to Jaunty's Xephyr package, you can simply use sudo aptitude install xserver-xephyr to upgrade it.