qw The Game ported to Android

I decided it's time to port qw The Game to Android, as a way to see how the publisher story works on Google Play compared to Ovi Publish and also to see how mature the Qt port to Android is.

For my port, I used Necessitas alpha 3 update 4, which you can download from the project website. Necessitas already includes both the Android SDK (that's the SDK you use in general, and contains all the Java APIs, etc..) and the Android NDK (that's used if you want to do native C/C++ development), so no need to install anything else. You can start Necessitas Qt Creator using "QtCreator/bin/qtcreator" in the Necessitas installation directory, but Necessitas also creates a launcher icon if you shy away from command lines.

The assumption is now that you have an existing Qt project with a qmake project file (.pro). Just open that .pro file in Necessitas Qt Creator and let it create the Android scaffolding. You can now try to build the project and run it - either in the Android emulator, an actual Android device or your N900, N950 or N9 running Nitdroid (the N950/N9 port is actually quite nice these days, and can be installed alongside Harmattan by flashing an open mode kernel with Android patches, replacing some init files and placing the Nitdroid rootfs inside /home/nitdroid/).

When you first start a Qt-based application on Android, it will redirect you to Google Play to download Ministro, which will take care of downloading the Qt libraries and storing them in a central, shared place, so that all Qt-based apps can use the same Qt libraries (which means that you can do closed-source apps, because they are dynamically linked to the LGPL'd Qt, and it also means that apps are smaller, because Qt doesn't need to be shipped with each app). One disadvantage is that the end user experience is not seamless on first startup, because your users will have to install Ministro first and wait for the Qt libraries to download.

Anyway, now you got that far and got your application running - or not. If you are missing libraries, and your application doesn't start, open the "Projects" tab in Necessitas Qt Creator and click on the "Run" tab for the Android target. There, open "Package configurations" and click on "Libraries" and check all Qt libraries that you need. When you compiled your application, there's a button ("Read information from application") that will analyze your binary and check the right Qt libraries. You can also add "Prebundled libraries", which are dynamically-linked shared libraries that will be shipped with your application. You can also check out the "Manifest", "Application" and "Permissions" tabs and configure it to your liking.

Protip: You can build the Android package on the command line using "ant" as soon as you have used Necessitas Qt Creator to create the initial scaffolding. The "android" folder will be created inside the folder where your .pro is located, and there you will find a build.xml.

Now to some code-level customizations that I had to do for my game, qw:

• QtMultimediaKit was not found - I had to comment out sound effects for now
• Automatic screen rotation - My game is landscape-only, and I had to tell the Android system in the AndroidManifest.xml file
• Qt.labs.particles was not found - Again, I simply commented it out for now; I guess these QML plugins should be easy to add to Necessitas, but I didn't bother to find out for this first try
• Screen resolutions! - Don't assume 800x480 (in case of the N900) or 854x480 (in case of the N950 and N9); make your app scale properly to the screen resolution at hand. Test this by creating a non-fullscreen window on your Desktop in different sizes, and see if the content looks right. For a quick'n'dirty first try, use QGraphicsView::scale

As far as the publishing experience goes: You have to pay a one-time fee of $25 to be allowed to publish to the Play Store (compare this to a one-time fee of 1 Euro for Ovi Publish and a yearly fee of $99 for the iOS App Store). What I found interesting is that there's basically no QA (apart from automated checks that are very helpful and give guiding error messages) and an application uploaded is published in a matter of minutes. I also like the fact that you can add a YouTube video link to the Play Store submission, so users can get a preview of how the experience is like. I published the app for free, and the UI warned me that it's not possible to convert a free app into a paid one in the future, which doesn't matter for me, but it might be a useful hint for other publishers.

qw The game is now available on Google Play for free. It's also available in Nokia store for free. Go play!

On app stores, compliance, packaging and tooling

I've been ranting about packaging requirements for app stores and the long roundtrip time and back-and-forth messaging that needs to take place until a package really gets published into an app store before. My experience here is with Nokia's Ovi Store and Intel's AppUp Center, and I'm obviously more interested in the Maemo and MeeGo-related parts (Ovi supports Symbian too, and AppUp supports Windows). First up, here are the documents that formalize the requirements:

• Maemo 5 Ovi Store Entry Requirements
• MeeGo Packaging and Compliance Guidelines

Both documents basically describe how packaging should take place, and this diverts somewhat from what upstream distros' packaging guidelines say (i.e. Debian in case of Maemo and Fedora in case of MeeGo). You have to install things in /opt, your binaries have to have a namespace to avoid clashes, there are different requirements for .desktop files and don't get me started on icon installation locations and sizes. Most of these things are already defined by freedesktop.org, but stores tend to have their own, incompatible rules. This means that as an application developer, you basically have to "rewrite" your packaging for every store/target/device, which is tedious and error prone.

Also, in case of Qt applications using qmake as the build utility, can't we have some magic qmake commands/macros that would do the Right Thing in terms of packaging for a given store? All that would be required is a list of metadata (name, "namespace"/domain name, description, category, ...) and an application icon, and the rest can be figured out by the build system (I'm thinking of the MeeGo Factory video here - put a qmake-based Qt source tarball in at the one end, and get an AppUp-compliant RPM, Ovi-compliant DEB, etc.. out at the other end - without having to care about distro-, store- or even device-specific packaging differences).

Apart from the fact that one has to do much special-casing, the other problem is that the rules are not always clear, and can be interpreted in multiple ways - the only way to find out if you picked the right interpretation is to wait for a few days (AppUp in my experience has been faster than Ovi Store with that) until you get feedback from the QA teams.

I would really like to have an automated "package checking" tool (provided by an app store vendor, i.e. Nokia or Intel) that I can run locally before I upload my packages, so that packaging bugs can be removed very early on (i.e. assuming 3 iterations to get the package right, and an estimated 3 business days of QA response time, the "upload and wait for feedback" approach would be approximately two weeks, whereas the "check locally using automated validation tool" approach would take about 3 days, because I can do the three iterations locally in about an hour and then wait 3 days for the QA team to check the contents, etc..).

So, my wishlist for a good app store - developer relationship:

1. Provide automated tooling to check for packaging errors/compliance
2. Make sure to align as much as possible with freedesktop.org and other app stores
3. Provide example packaging, add positive and negative naming/config examples to the docs
4. Provide an easy way to check for and fix package dependencies
5. Allow developers to submit new versions from the command line / via scripts (requiring the developer to go to a website and using an upload tool is not developer friendy :/)
   
6. Allow developers to upload new versions while an old version is still in QA (AppUp, I'm looking at you)

I'm really starting to wonder if it wouldn't be better to integrate the app stores more with tools like OBS and other developer-friendly utilities, and looking forward to better developer experiences in Ovi and AppUp in the future. In the mean time, I'm really happy with the meego.com Community OBS :)

Ovi Store Requirements vs. Extras Testing QA

If you want to publish your applications on Ovi Store for Maemo 5, you have to fulfill certain criteria for the package to be accepted. The technical ones are listed in the document Maemo™ 5 Applications: Ovi Store Entry Requirements. Here are some problematic entries that were not clear to me in the beginning (coming from Extras QA and a Debian-based background):

• The file must be named myapplication_1_0_1.deb (for an application that is called "myapplication"). Interesting factoid: The version number must include three digits (one can interpret that as "no less and no more"). That's different from the Debian standard naming of myapplication_X_armel.deb (where "X" can be any format version number, and "armel" specifies the target architecture). So if you have packaged your application, make sure to rename the file after upload.
• The relation of the file size of /opt compared to the files in /usr must be greater than 1:80. Here's an example from That Rabbit Game: /usr contains two files: The icon (7kB) and the .desktop file (128b) and /opt contains one file: The binary (658kB). However, the difference between these two is not a factor of over 80 when compared with "du -sh" (depending on the filesystem settings).

With that said the structure of the testing criteria in that document is very clear and (apart from some problems with the detailed specs), everything is understandable, well thought-out and can be tested by following the instructions in the document. Some of these could be use to "formalize" the Extras-Testing QA checklist here on Maemo.org or at least provide an easy-to-follow guide for carrying out the basic tests.