Airsource woke up this morning to Nokia’s announcement to make Symbian an Open Source platform, and with it all the concrete platforms like S60, UIQ, and so forth. While Motorola, Sony Ericsson, and NTT DoCoMo are all mentioned in the press release, it seems to me that they had little choice but to jump on board. From an Airsource perspective, S60 pretty much meant Nokia - and now Nokia will mean S60. At the very least, that might make our sales presentations easier.

This announcement is good news in two ways for Airsource’s business. Firstly, from a commercial perspective, it removes some of the cloud of doubt about what Android means for the market. Android did not exactly threaten the future of S60, the established leader in the convergent devices market , but it did cast some doubt on the subject. How would an open source competitor affect the market? Businesses, of course, hate doubt, and while S60 was ahead of Android on pretty much everything apart from source access, the playing field there has now been made more level. Obviously a $1500 charge (annual) for source access is not free, but it is vastly cheaper than the old fee to become a Symbian Platinum Partner.

Secondly, from a technical perspective, access to the underlying platform code helps the developer produce more stable products, faster. Some areas of code are always technically more complex and more poorly documented than others, such as MTMs. Access to source code will significantly ease development on the really cool stuff.

We at Airsource look forward to seeing more developments.

The Cambridge CAMRA Beer Festival has arrived in town again.

An annual event in Cambridge, the Beer Festival features hundreds of brews from all over the UK and Europe. The key message is that the best beer is “Real Ale”; not stuffed with preservatives and artificially carbonated but the genuine, hand-crafted article.

As a team bonding training exercise, the Airsource team went along to learn more about Real Ale and to sample a few ounces of the amber brew. The work was strictly investigative and rigorously scientific.

The main hall features food and, obviously, large quantities of beer.

A few hints for those unaccustomed to the beer festival;

• Work a half-pint at a time
• The cheese stall is brilliant
• Leave the more potent brews for later in the evening

Inside the Cambridge Beer Festival compound.

My vote for the best beer experienced this year is “Comrade Bill Bartrams Egalitarian Anti Imperialist Soviet Stout” which is very much worth your time and energy.

As part of our scientific study, obviously some beer needs to be consumed.

I stayed at the Yotel in Heathrow Terminal 4 the other day. I had an 11am flight to the US, and decided that instead of a 6am start from Cambridge, it made much more sense to stay literally 50m away from the British Airways checkin desk. This made me an accidental, but much appreciated, beneficiary of the T5 shambles - BA are keeping a lot of their long-haul flights in T4 until the new terminal has properly bedded down.

I arrived at the Yotel’s reception, aka “galley” at about 10pm. After a slight modification to my booking, I headed off to my “cabin” (there’s a bit of a shipping theme), gained access with the ubiquitous card lock, and then headed straight for the shower. Two seconds later I realised that there was a window in my room, facing directly onto the corridor! I promptly closed the blind, but I really don’t see the point of this window. Why would I want to be able to see onto the corridor - and vice versa?

The Yotel concept is that you get a small room - about seven square metres - comprising an electrically folding bed (think business class seats) which is actually pretty comfy, a bathroom, a tv, and so forth. There’s even a desk and chair, both of which fold away. Except the desk didn’t. It got stuck half-way down.

Fortunately it didn’t obstruct the bed, but it did mean once the bed was extended, the only path from bathroom to door was to climb over the bed.
Careful readers will be wondering where your baggage goes. Yotel have thought of that - the bed is pretty high off the floor, and there’s storage space underneath it. There’s also somewhere to hang a suit up.

The desk has power points and a network connection just above it, though I have to report that the network connection didn’t work. For the technically minded, it assigned an IP address, but failed to pass any packets. Rather than try and fix Yotel’s network for them, I just went outside (too much metal inside to get a signal) and made a phone call instead, over a pleasant pint at Weatherspoons.

Apart from the desk and the network connection, I was pretty pleased with the room. There was some building work inside Heathrow that night, but earplugs (available from reception) completely blotted that out - and if you sleep in a standard airport hotel you just get to hear planes and traffic in any case. I slept well (almost too well, I missed my watch alarm, but had set up a backup wakeup call on the TV, which I recommend, because it turned the lights on as well), the shower was good, and it was a 1 minute walk to check-in in the morning.

Does it have some issues? Yes. Would I stay again? Yes.

I’ve just been taking a look at Device Atlas, which in its own words is the “world’s most comprehensive database of mobile device information”. I had high hopes, but unfortunately it appears to be rehash of the kind of information which is readily available, without anything more useful. I appreciate that this database is not designed for my sole delectation, but I surely can’t be alone in wanting to get a list of devices running S60 FP1 which have a camera? Not only does the Device Atlas apparently not allow any sort of search, it doesn’t tell me what operating system a phone runs, what JSRs it has, or allow any kind of user commenting (e.g. “HTTPS is broken on this device”).

My favourite part of the site is in the FAQ, where it says “Can I have a job? Yes, we’re hiring world class staff for the DeviceAtlas project. Call us.” Errr, call who? There’s no phone number. Click on “Contact” on the nav bar at the bottom of the screen. Still no phone number. I presume you’re supposed to call dotMobi (one more click away) rather than Device Atlas, but that’s far from clear. Also in the FAQ, we read that “We intend this to be the single largest, most comprehensive, and accurate device database on the planet”. A worthy goal - but Device Atlas has a long way to go to reach it.

When we set up Airsource, we set it up as a BREW consultancy. We rapidly sold a number of BREW projects, and built on the expertise we had acquired while at QUALCOMM. In the process, however, we inevitably found ourselves working on other software platforms, particularly on Series 60, which now accounts for about half of Airsource’s work. Series 60 and BREW are often held up as competitors, though in practice I would argue quite strongly that they target very different markets.

A BREW phone, such as the Motorola V3M has a primary display is 176×220, it has 23MB of memory, and a processor clocked at perhaps 40MHz. A Nokia E65 costs nearly twice as much, has twice as many pixels, can store five times as much, and runs fives times faster. Pundits will immediately point out that the V3M is a pretty slow example of a BREW phone. That’s certainly true, but the V3 series accounts for a very significant fraction of the US market for BREW phones. The Nokia E65 is similarly chosen for comparison as an example of a popular Series 60 v3 phone.

Comparing the two is pointless. The BREW phone is clearly a much lighter-weight platform, targetted primarily at games. The Symbian phone has considerably more memory, more storage, faster CPU, and generally faster network data transfer. It is also significantly harder to program for - in the same way that coding for a Windows XP PC requires rather more knowledge than writing a program in BBC BASIC did. A Symbian phone is simply more capable than a BREW one, and consequently the APIs are richer, and the learning curve steeper.

That’s not to say that that Airsource’s clients do not want to target their application at both BREW and at Symbian. They absolutely do. But the Symbian application will always have more functionality and tighter device integration than the BREW application, in the same way that a dedicated BREW application will have more functionality and tighter device integration than a web-based application. Clients come to us because they want to get the most out of the phone, and to do things that are non-trivial, whether that be linking into the messaging menu of a Symbian phone, porting a multi-process application to BREW, or simply writing an application that Just Works.

What this means is that while the mobile market is certainly split into markets that may not directly compete with every other platform, they form an overlapping whole that represents the mobile space. Companies want to get their application “on mobile”, and by that, they mean on the maximum number of phones, with users who will spend money, for as little cost as possible. Choice of platform, like Symbian, or BREW, is therefore just a business decision, not a technical one.

It’s 5:30am and the annual wireless industry hoe-down (now in it’s second day) is taking place in Barcelona. In order to avoid the rush, crowds and expensive Easyjet flights, I’m flying out a day late and looking forward to see what’s in store for the industry during this coming year.

Stansted is gradually becoming a nice airport…

The wireless industry seems to have a “pulse” - there are a flurry of handset releases around Easter and a blizzard of handsets released around Christmas. This release cycle feeds back into the software development industry, so if you work back from handset release dates you can get a picture of what your year will look like. Subtract 4-8 weeks for handset field testing and another few weeks for certification and you can see that you have certain dead spots, at least during the months of January and August.

Certainly what we discovered last year was that we experienced a real “dead spot” during the time of 3GSM (the precursor to MWC). The reason for this seems to be that everyone is either getting ready for or coming down from the conference. Someone pointed out to me, though, that rather than dreading the dead spots you need to enjoy them because in this industry they don’t last for very long.

What are we looking forward to this year? What is coming down the pipeline in the industry that may change the way we all do business? The big ticket items;

• No more Motorola
• Good flat rate data tariffs
• The iPhone SDK
• An Android handset

Motorola has received a good kicking of late, and despite defining the early years of mobile and having the smallest and grooviest handsets a few years ago, they seem to have lost their way. An ex-Motorolan myself, I can say that they have some truly awesome engineers on staff but there is a distinct lack of leadership and vision in the middle and upper ranks. So what’s to happen to them? The most likely scenario I can see is that they are bought up by a far-Eastern manufaturer and quietly sink into oblivion. Maybe Google can buy them and use their handset wisdom to seed the market with Android. Yeah, not likely. So I think Motorola’s handset business is history, and judging by their dribble of handset releases at MWC it’s looking like it won’t be long before the mobile phone pioneer has to make a quiet exit.

Good flat rate data tariffs may be on the way as well. The EU Commissioner Viviane Reading has cracked the whip on data roaming charges and maybe this will spur the lumbering operators into action to set up flat rate tariffs that are affordable and reasonable for all. Cheap data access will be a spur to the small, hungry handset software development community and will transform the landscape. All it takes is one…

It’s unlikely we’ll hear much about the iPhone SDK before the end of Feb. As a newcomer to the industry, Apple forges it’s own path. I’m not, for example, expecting to see much activity from them at MWC. They want to control their own coverage very carefully and orchestrate their own events. Maybe they will have a sideline event of some kind. But I’m not expecting much activity.

My colleague Teanlorg has already given us some analysis of Android and the challenges that await Google on the device. Reports suggest some early device prototypes are creeping out at MWC so I will keep my eyes peeled for them. If a device is in prototype form now, though, this suggests that an end-of-year launch is still a possibility. But if we haven’t seen anything more solid by mid-year we could be waiting until well into 2009 before anything emerges.

There’s a lot to look forward to this year in the mobile world. New platforms, old players fading out and hopefully cheaper network access to come. I’ll be bringing you more from the show and surrounding events over the coming days.

After a much-awaited Release Day and the obligatory pub afterwards, last Thursday marked the end of January and Android Code Day in London and Tel Aviv. It was my first time in Israel, which made it more exciting As much as I’d like to visit Israel, I wouldn’t be able to justify the expense (it might happen in the future with the current trend in ticket prices). The good news is that the train journey into London is relatively short and painless.

After waiting around in the lobby, we were eventually escorted through brief NDA-signing (is it legally binding if there’s no expectation for you to read it at all?) and then upstairs, into a meeting room just big enough to hold 40 people and their laptops without feeling crowded.

The first half of the day was taken up by a brief presentation by Jason Chen, interleaved with a not-so-brief and highly interactive question-and-answer session. Then there was lunch, with the usual perks (who wouldn’t work for Google for a freezer full of Ben and Jerry’s?) and some insight into Google’s business strategy.

Top-secret plans

We started the afternoon with a brief demo of an Android app from an audience member. It was pretty decent for only two days’ worth of code and some borrowed sprites — maybe Android phones will compete with the PSP (in keeping with tradition, they’ve tested Quake on Android prototypes, with reasonable performance).

A familiar game…

… stretched by OpenGL in landscape mode

The “hackathon” commenced, but as the average level of experience was “has compiled and run the hello world app” (and the documentation is written in the traditional Javadoc style that never manages to tell you how to do what you want to do), I don’t think much coding actually happened — that wasn’t really the point of the day. Jason Chen is a Developer Advocate; so’s Dan Morrill (the first link in this article). He writes “I get to travel the world to meet developers and talk about cool technologies. I can’t believe I get paid for this!” though Google is keen on hiring more Developer Advocates.

It’s not hard to see why: the room seemed to consist of people from handset manufacturers, mobile OS companies, people wanting to see if Android is worth investing time into, and people there just to keep track of what Google was up to — in fact, the last category seems to cover everyone.^[1] One of the most promising things about Android is an abundance of cool, novel, well-written, currently nonexistent apps — it’s a chicken-and-egg, and Google can only hope that apps are easier to produce than users (what do you think the Android Developer Challenge hopes to accomplish?).

Of course, it’s really future users that give decision-makers the incentive to spend money on a particular platform. Until we invent time machines, we’ll have to settle for a significantly high probability of a significant number of future users. The greatest impediment is actually having phones for sale, but the problems there are largely political, and if I started on politics I’d be here all day. Once phones are on the market, there’s another problem:

Android has to be good.

And by “good”, I mean better than the next phone on the shelf. Of course, customers define what’s “better”, but what do you see when you go phone shopping?

• The brand is difficult to change.
• The design is difficult to do well, but at least the OHA has Motorola.
• The “specs” that the shop decides to show are rather arbitrary.
• The price matters, but in the UK, it’s largely “free on contract” (at least Android is free, so manufacturers can save on licensing fees).
• What your friends say is even harder to change.

Word-of-mouth is often mentioned as the most important form of advertising, and also the hardest to get right (should I be worried that nobody seems to know what Android is?). But personally, if there’s anything that’ll make me recommend one phone over another, it’s the UI, probably because it’s the thing which irritates me every time I use a phone — it’s also where Android has a chance to shine, since (in theory) you can rewrite everything, even if you end up with a bloated home screen app that does everything under the sun.

Without going into technical details (there’s plenty on YouTube), Android has a few distinguishing features; the most notable is that it tries to be designed around the user experience. Intents are a key idea — they encapsulate what the user wants to do. The system passes the request to whichever app says it can fulfil the intent — apps aren’t replaced, intents are.

The problem arises when you have many apps which want to provide some basic enhancement. If I have Skype on my Android phone, here’s what I’d like to see:

• Skype status shows up in the contact list.
• Calling a Skype-online contact makes a Skype call over Wi-Fi.
• Calling a Skype-online contact asks me before using HSDPA, in case I don’t want to end up with a big phone bill and violate the no-VoIP clause of the ToS.

It’s conceptually easy, with one catch: you don’t want to replace the contacts and dialler, because apps can’t access another app’s data. It’s difficult to do the right thing when you change contacts apps between adding, removing, editing, and renaming contacts, and it doesn’t work with Google-talk or Gaim Pidgin, let alone a psychic dialler which reads my brainwaves and calls the right person without me asking.

What users expect is the concept of a global address book, with each contact (an ID) optionally linked to names, phone numbers, e-mail addresses, snail-mail addresses, WGS84 coordinates, IM usernames, and anything you might associate with a person (or group of people).^[2] Similarly, apps which handle intents (”send a text message”) can also advertise a “quality factor” (RFC 2616) that changes dynamically, so that Jabber’s “quality” drastically decreases when I move out of range of Starbucks and my phone starts using roaming HSDPA, hopefully going below a threshold which prompts the phone to ask me first. Suddenly, my phone has a better IM client than my computer: it’ll switch to SMS when Wi-Fi isn’t available, connect to the office’s SIP server, and give me the directions to tonight’s party.

There’s been little work on any platform to address these; as a result, there always tends to be one app that ends up on top with everything else struggling to catch up — IM clients throughout the decades have followed this trend. Phones are a different matter, and unless something reaches critical mass, we’ll just end up with a lot of fragmentation. While compatibility issues aren’t an aspect of fragmentation that the audience seemed to be worrying about (people seemed more worried about OEMs taking Android and making it proprietary), they’re important to the user experience: seamlessly integrating apps together is an important part of a good UI.

Another thing which doesn’t exist in Android is input methods — the current emulator only supports primitive touch screen and a keyboard. How will multitap work? What about graffiti, handwriting recognition, or an on-screen keyboard? These tend to require extra screen space, which means it has to be coded into each app or provided by the system; there’s currently no easy way to give another app a certain portion of your screen. Besides, the keyboard should only appear when I’ve selected a text field (and it should let me write/graffiti directly into a text field). What about gestures? Or force-input?^[3]

When you control nearly everything about a device, it’s much easier to make a good UI instead of just a decent one — the iPhone kept coming up as an example of a good UI throughout the day.^[4] Android will stand between everybody’s apps and the underlying hardware, whether there are 30 keys or none, and it needs to provide enough abstraction so that developers can rely on the system to do the Right Thing and still give a good user experience. It’s what Android is designed around.

At last, the day came to an end, and I left for King’s Cross. Though the room was teeming with skepticism, Android is something that I’d like to succeed, and I’ll be watching the OHA’s four handset manufacturers closely over the next few months (maybe Motorola will finally make a phone that looks pretty but doesn’t irritate me every time I try to use it).

There’s going to be another Android Code Day in Boston on the 23rd. It’s worth going to, especially if the impending SDK update, happens first. Besides, you can always enjoy the Ben & Jerry’s on the mission to uncover Google’s master plan.

1. Working with mobile software imparts a strong urge to know what everyone else is doing, possibly to learn from those who have done it better than you, or in search of the next great platform which is reasonably profitable and both a joy to use and code for (my recent experiences with a certain OS/IDE/build system can be summarised as it should not be this difficult!).
2. One can only hope that it won’t be implemented using XML.
3. Want to turn the alarm off? Hit it. This is probably patented. The W380a lets you turn off the alarm by waving at the camera.
4. The iPhone and the BlackBerry the two phones which I hear described as good, not just better-than-something-else.

I recently had the dubious pleasure of debugging a User 42 Panic on a piece of Symbian code that was given to me by another company. You always need to make sure you understand what the system is telling you, so I went straight to the documentation:

User 42: This panic is raised by a number of RHeap member functions, AllocLen(), Free(), FreeZ(), ReAlloc(), ReAllocL(), Adjust() and AdjustL() when a pointer passed to these functions does not point to a valid cell.

Hmmm. That didn’t really give me many clues. Well, I needed to figure out how to reproduce the bug anyway. That was relatively easy, I could reproduce it with a User::Leave(). The leave was being trapped, and the debugger showed the panic was being issued between the Leave and the TRAP, so that pointed to a problem on the CleanupStack (which agreed with what the documentation said). Isolating the problem even further showed that I could reproduce the problem by doing this:

CItemBase* item = (CItemBase*)decoder->ReadItemLC();
CleanupStack::PopAndDestroy(item);

For reference, ReadItemLC() constructed an MDecodable, and the inheritance hierarchy looked like:

Ignoring the fact that a function called ReadItemLC() should return a CItemBase*, not an MDecodable*, the problem here is that in that inheritance hierarchy, both CItemBase and MDecodable have their own data (MDecodable has a vtable pointer, even though it’s an abstract class). Consequently when you cast a pointer from an MDecodable* to a CItemBase* you get a different pointer value. Try the attached code on any system for a demonstration of the problem.

However, in the code sample above, the CItemBase class had not been fully defined; we had simply forwarded-declared CItemBase. That meant the compiler couldn’t do the necessary arithmetic (subtract 4) to convert an MDecodable* to a CItemBase* - because it didn’t know whether they were actually part of the same inheritance tree, or completely dissociated types. So it did the equivalent of a reinterpret_cast.

When I changed the code to do the correct C++ style cast:

CItemBase* item = static_cast<CItemBase*>(decoder->ReadItemLC());
CleanupStack::PopAndDestroy(item);


It promptly failed to compile, because CItemBase hadn’t been fully defined. Adding

#include "ItemBase.h"

at the top of the file fixed the compile - and fixed my User 42 Panic as well.

Lesson: next time I get code from another source, check the casting is done properly.

This blog has been going for nearly a year now - our first post was on January 29th. Airsource has been around for a little longer than that - I quit my job at QUALCOMM to work full-time at Airsource in June 2006. We’re approaching the end of the year, so what better time for a bit of a review. I’m going to stick to the technical side of things - I’m sure Nick will have something to say, and maybe one of our new employees will want to give their view of things too.

There are several key things I’ve learned in my time at Airsource. The most important one is that when it’s your own company, it’s not enough to be good, or even just better than the next guy. You need to be great. Every time I write code, at the back of my head is the feeling that some day this code may be run by a customer. And it had better work, because if it doesn’t, one way or another it will be my problem. No matter how principled you are, that ethos simply doesn’t apply when you’re working for a large company. You write the code, you test it, the QA department passes it, and you walk away. You don’t even have to do any sales!

The corollary of this is that it’s not just enough to write good software. It has to be the right software. By that, I mean that you need to make absolutely sure that you know what the customer is asking for - and that what the customer is asking for is really what they want. And then, you need to deliver that, deliver it well, and ideally deliver just a little bit more. You don’t want to give the farm away, when consultancy is what keeps a roof over your head, but you do want to give the customer a warm fuzzy feeling.

If you are writing a product, you don’t develop the thing in a clean room and then unleash it on an unsuspecting public. Or if you do, it will probably flop. You do some market research first. You do usability testing. You go out there and find out what people want. In the same way, when working on a client project, it’s your responsibility to make sure you are doing what the customer wants. And remember, even if what the customer is asking for sounds stupid, there’s a reason behind it. At least when you’re a small software company, your customers are almost guaranteed to be making a lot more money than you are. Which means they’re doing something right.

When Airsource finishes a customer project, we send someone along who didn’t write any of the code, and had as little involvement as possible with the project. They sit down with the customer, and do a post mortem. The customer gets the chance to voice any and all complaints that they have. They are surprisingly frank. I’ve had some feedback about me that people would never give to my face. And then, when we’ve got the feedback, we sit down together at the office, and figure how to make the next project an even better experience for the customer.

The Airsource team have just been out for their first team-building exercise. One of the benefits of running your own company is that you get to choose what the activities are - and since my sport is running, and Airsource is a four man company, I decided we’d do the Cambridge Fun Run - a four by 1.1 mile relay. I did check that everyone was up for a bit of running first though! We’ve just got back from the race - via the pub, so that’s an average of 7 minutes running each followed by an hour eating and drinking. Seems a good ratio. Not sure how we placed yet, but those who know me will know I’m not exactly uncompetitive, so I’ll be checking the results with interest!