“Google Mobile are moving all development away from downloadable apps to the mobile web”
That’s a message mjelly records Charles Wiles, product manager for Google Gears for mobile, as making at this week’s MoMo London event.
I was at the same event. I’m not sure I remember hearing quite such an emphatic message as mjelly reports, but I do remember hearing the following:
- Eric Schmidt (Google CEO) has been asking the Google Mobile team why they only make one app release every six months, whereas development of apps for PC web-browser happens much more quickly
- Downloadable apps for mobile devices are fraught with problems – including BIG issues with device fragmentation
- Taking Google Maps for mobile as an example: there are 10+ platforms to support, requiring 100’s of builds in total – it all adds up to PAIN
- There must be a better way!
- The better way is to deliver services through the mobile web, instead of via downloadable applications.
I’ve heard this kind of message at previous MoMo London events, from lots of different speakers. Downloadable applications (whether written in native C++ for in Java) introduce lots of problems with development, deployment, and usability, whereas mobile web apps are a whole world simpler. The message that comes across is: If you want rapid development that in turn allows rapid innovation, stick with the mobile web. It’s not a message I’ve enjoyed hearing, but I can’t deny that lots of speakers have said it (in various different ways).
But what made the presentation from Charles Wiles all the more interesting was that, after highlighting difficulties facing downloadable mobile apps, he was equally critical of mobile web applications (which run inside a web browser environment on the device):
- Mobile web apps suck too!
- There’s often high network latency
- The mobile web apps lack access to location, the address book, and camera, etc.
It’s for this kind of reason that Google has continued to release downloadable versions of their most popular applications. (Incidentally, pride of place on the Quick Access bar on my Nokia E61i idlescreen are the native C++ versions of Google Search and Google Maps. They’re in that pole position because I find them both incredibly useful.)
It’s also for this kind of reason that Apple’s initial message about how to develop apps for the iPhone – that developers should just write web applications – was so poorly received. Would-be iPhone developers strongly suspected they could achieve better results, in many cases, by writing downloadable apps. This expectation has been vindicated by the heady events around the recent launch of the iPhone application store.
Four challenges facing mobile web apps
The four factors I generally highlight as limitations in mobile web applications vs. downloaded apps are:
- The UI provided by a web browser is general purpose, and is often sub-optimal for a more complex application on the small screen of a mobile device (an example of the unsuitedness of the web browser UI in general is when users are confronted with messages such as “Don’t press the Back button now!” or “Only press the OK button once!”)
- Applications need to be able to operate when they are disconnected from the network – as in an airplane or during a trip in an Olde World London underground train – or whenever reception is flaky. On a mobile device, the user experience of intermittently connected “push email” from the likes of BlackBerry is far more pleasant than an “always connected web browser” interface to server-side email
- Web applications suffer from lack of access to much of the more “interesting” functionality on the phone
- Web applications are often more sluggish than their downloaded equivalents.
Exploring two routes to improved mobile apps
So what is the best answer? Improve native mobile app development or improve mobile web app development? Unsurprisingly, the industy is exploring both routes.
To improve mobile web app development:
Each of these initiatives (and I could have mentioned quite a few more) is significant, and each deserves wide support. Each of them also faces complications – for example, the more AJAX is included in a web application (addressing problem #1 of the four I listed above), the more sluggishly that application tends to run (exacerbating problem #4). And as web applications gain more access to underlying rich phone functionality, complex issues of security and application validation rear their heads again. I doubt if any of these complications are fatal, but they reinforce the argument for the industry also looking, in parallel, at initiatives to improve native mobile app development.
To improve native mobile app development, Symbian has been putting considerable effort over the last few years into improved developer tools, developer documentation, APIs, and so on. The results are encouraging, but the job is far from done.
Quick recipes on Symbian OS
One of the disincentives to doing native application development on Symbian phones is the learning curve that developers need to climb, as they become familiar with various programming idioms. That’s a topic that Kari Pulli (Nokia Research Fellow) discussed with me when he visited Symbian HQ back in Fall 2006. Kari had in mind the needs of people (especially in universities) who were already good C++ developers, but who don’t have a lot of spare time or inclination to learn brand new programming techniques.
We brainstormed possible titles for a new Symbian Press book specifically targeted at this important developer segment:
- “Symbian progamming in a hurry”?
- “Hacking Symbian OS”?
In the months that followed, this idea bounced around inside Symbian, and gathered more and more support. The title changed in the process, to the more ‘respectable’ “Quick Recipes on Symbian OS”. Michael Aubert stepped forwards as the lead author – you can read an interview with him on the Symbian Developer Network. Happily, the book went on sale last month. For my hopes for the book, I append a copy of the foreword I wrote for the book:
This book has been designed for people who are in a hurry.
Perhaps you are a developer who has been asked to port some software, initially written for another operating system (such as may run on a desktop computer), to Symbian OS. Or perhaps you have to investigate whether Symbian OS could be suited to an idea from a designer friend of yours. But the trouble is, you don’t have much time, and you have heard that Symbian OS is a sophisticated and rich software system with a considerable learning curve.
If you are like the majority of software engineers, you would like to take some time to investigate this kind of task. You might prefer to attend a training course, or work your way through some of the comprehensive reference material that already exists for Symbian OS. However, I guess that you don’t have the luxury of doing that – because you are facing tight schedule pressures. There isn’t sufficient slack in your schedule to research options as widely as you’d like. Your manager is expecting your report by the end of the week. So you need answers in a hurry.
That’s why Symbian Press commissioned the book you are now holding in your hands. We are assuming that you are a bright, savvy, experienced software developer, who’s already familiar with C++ and with modern software programming methods and idioms. You are willing to work hard and can learn fast. You are ready to take things on trust for a while, provided you can quickly find out how to perform various tasks within Symbian OS. Over time, you would like to learn more about the background and deeper principles behind Symbian OS, but that will have to wait – since at the moment, you’re looking for quick recipes.
Congratulations, you’ve found them!
In the pages ahead, you’ll find recipes covering topics such as Bluetooth, networking, location based services, multimedia, telephony, file handling, personal information management – and much more. In most recipes, we provide working code fragments that you should be able to copy and paste directly into your own programs, and we provide a full set of sample code for download from the book’s website. We have also listed some common gotchas, so you can steer clear of these potential pitfalls.
Since you are in a hurry, I will stop writing now (even though there is lots more I would like to discuss with you), so that you can proceed at full pace into the material in the following pages. Good speed!