Nokia MeeGo and Belle

nokia.gifAs Nokia’s late MeeGo and Symbian offerings get released, we start to get a closer look at what Stephen Elop saw, back in February, when he decided to drop them for Windows Phone. 

Surprisingly, the MeeGo based N9 was widely acclaimed and now, Symbian Belle is getting great reviews. According to ZDNet it brings Symbian closer to iOS and Android. In the same article, Francisco Jeronimo, research analyst at IDC says "If Nokia had launched this new Symbian Belle one year ago, the company would have remained the worldwide smartphone market leader".

Sadly, we hear more and more about where the N9 won’t be released and as for Symbian, most network operators have already stopped buying Symbian^3 devices as they see them as obsolete.  Meanwhile, Nokia’s share price was down over 50% on February and recently made a slight recovery to about 40% down. I hope people aren’t depending on MeeGo and Symbian Belle as these won’t be Nokia’s saviour.

It’s looking more and more like Nokia should have stayed with Symbian and MeeGo in the medium term. I have thought for a long time that Nokia’s fight had already been lost to Android and MeeGo. I continue to think there’s no point using Windows Phone in this fight. Nokia should be concentrating on next generation devices, for example with new input mechanisms and innovative display technologies, rather than betting everything on something (Windows Phone) that’s just trying to catch up with iOS and Android. Nokia has shown that MeeGo and Symbian Belle were good enough to compete in the medium term.

Nokia N9 Apps and Development

nokia.gifNokia have finally announced their first (and probably last) MeeGo phone. This is the culmination of years of effort, many blind alleys and u-turns. I am not sure why Nokia released it given their new Windows Phone strategy. I suppose there was so much already done and in the pipeline that it made sense to at least show some capability in between ditching Symbian and introducing Windows Phone. Most Nokia phones are sold via network operators and according to some I have spoken to, they have already ‘turned off’ thinking about Symbian and MeeGo phones so I suspect very few will sell via this channel. Instead, it will become much like the N900 for people who want to experiment with the software in their phones.

From a user and developer viewpoint there are lots of misconceptions as to what apps will run on the N9. People are speculating that existing Qt apps for Symbian will run on the phone which isn’t strictly correct, not least because the N9 won’t be accepting .sis files. There will also be other small inconsistencies related to how the Qt needs to do things slightly differently on MeeGo (different preprocessor symbol for the technically oriented) and some UI assets might need slight changes for optimal viewing. However, it will be possible for Qt developers to easily modify and rebuild their apps to run on the N9. Whether they bother to do so is another matter.

Nokia and Qt

nokia.gifNokia reached a significant milestone today. However, more recent events at Nokia have turned something that would have been very significant into something very few people will care about.

What I am talking about is the release version of Qt SDK 1.1 and more importantly the possiblity to publish applications on Ovi that make use of Mobility 1.1 (i.e. significant useful device APIs). As long ago as December 2009, I was declaring Qt not fit for commercial use. Since then, there have been so many promises, announcements and tech previews but no way to publish a Qt app that uses significant device APIs. Today is the day that Qt becomes technically viable for many projects. What’s more, it now includes a release version of QML that provides a much easier Javascript-esque Qt development environment rather than having to use c++. Unfortunately, all this is less exciting now due to Nokia’s new strategy.

What can we all learn from this (Qt)? Release less, but more often. Analyse the technical aspects deeply before assuming ‘buying in’ a solution will dovetail with your needs. Think about timing. Particularly think about dependencies. Qt depended on future UIs that theselves were uncertain. If you fail, be flexible and think how things might be re-purposed.

Nokia Qt QML

qt.gifQML is Nokia’s new declarative language to build Qt UIs and apps. It’s what Nokia is recommending developers (and its internal developers) use to develop new apps so that they will be compatible with current/future Symbian OS-based and future MeeGo-based devices.

I have been using QML for a few weeks. Here are my thoughts…

  • QML feels a little like Javascript. Unlike c/c++, you don’t have to worry about memory allocations and it’s not strongly typed. There’s no compilation which means most syntax errors get found at run time. However, running apps is fairly quick (using the QMLviewer under emulation) and you can re-run your app without restarting the emulator.
  • Once you have used it for a short while, QML is significantly easier to develop for than Symbian, iOS, and even Android.
  • There’s no standard UI for next-gen Symbian or new MeeGo because Nokia are still working on them. For this reason, there’s no framework yet for creating screens and widgets/controls. Instead you have to deal with rectangles, mouse events, images etc. This means you have you build up your own UI. There are examples how to build your own buttons, edit boxes etc so it’s not as onerous as you might think.
  • The IDE, QT Creator, used to edit/build qml files is proprietary rather than Eclipse-based so you end up missing lots of features you might take for granted. 
  • One disadvantage is that because the files describing your screens/code are not compiled, they remain readable to hackers should they try to uncompress your installer. Nokia need to look into this and provide some kind of source encryption. UPDATE: I have since been informed by Nokia "Adding your QML files to a QRC (resource file) will get them compressed and compiled into the binary". To use these files, you reference your first QML file (in c++) from a resource, all further relative requests for files come from the resource. Further tip: Don’t put large graphics in a resource as they get hexdumped which bloats the executable hugely – if your first qml comes from resource you can later reference outside the resource using ‘file:<filename>’.
  • The forums on are a great place to ask questions if you get stuck.

Unfortunately a lot of the existing documentation (and many Qt developers) still uses the older QWidget-based development that isn’t suitable for today’s touch screen devices. I think Nokia needs to put more effort into converting developers (and developers for developers) to Qt QML.