News

Welcome to the world of mobile phone chaos: software takes over

A mobile phone show... an exhibition where, you might expect, new phones appear, new toys, and new sexy downloads are shown, and mobile operators display new services. Wrong! - it's a software developer paradise, complete with convenient software developer Hell.

The Symbian show in London's Excel centre this week is, not surprisingly, sparsely attended (see the Hunkymouse's rant about transport) but that doesn't mean it's not interesting. It may be pivotal.

Imagine the old days of the PC industry - in the days before they were called PCs, and were called Microcomputers. If you wrote a program for the Oric Atmos, it wouldn't run on Oric's own alternative model, the Stratos; it certainly wouldn't run on a Commodore Pet, or a Tandy TRS-80 or a Bear computer from the New Bear computer company. If you wanted the same program to run on a Sinclair Spectrum, you had to re-write it.

It's misleading to compare today's phones too closely with those old computers. Nonetheless, the principle applies: too many of today's phones are unique from a software developer's point of view.

The problem, oddly, isn't the smartphones. They fall into neat categories, and a developer can cover a huge swathe of the market simply by writing software for the Nokia Series 60; or you can write for the Microsoft .Net compact framework and expect a lot of phones, including Symbian phones, to run it.

No, the problem seems to be the "feature phones" which one estimate yesterday at the Symbian show put at "well over 150 different platforms" from the software developer's point of view.

To some extent, you can develop for that common platform, and write your software in Java. Even that, it seems, is fraught with "opportunity for chaos" because, with so many different phone operating systems, each group of engineers has implemented their own version of the Java platform, and there are some subtle differences. And there are some not so subtle differences.

The problem arises because these things were never intended to run generic software, according to Morten Grauballe [above, left], marketing director at Red Bend. His job is to download software updates into phones by selling firmware over-the-air (FOTA) mobile client software to the phone manufacturers; and he's predicting problems.

"Compatibility is the issue, even with Java," said Grauballe. "We're working with the Open Mobile Alliance standards for software components, and that will help. But already, we're starting to see situations where an update which works on one phone will crash another identical phone - because it's running another software application which the user has loaded. And the two can't co-exist."

The cause of the problem is memory availability. Two years ago, a smartphone would have had less memory than the typical feature phone has today.

Writing an operating system isn't actually as hard as people make out. Computer pioneer Iann Barron - famous as the founder of UK semiconductor company Inmos in the late 70s - was a computer designer before that. He was fond of saying:

"The correct way to write an application, is to start with the software, and then design a computer language which best expresses the problem, and then design an operating system which handles it, and only then, design the computer to run it." And indeed, he designed literally dozens, maybe hundreds, of completely unique systems for defence contracts in his time.

That approach may seem ludicrous in today's mass market culture but in reality, that's exactly what feature phones have been doing. Phone companies have produced a design which has certain features, and no other features; and then produced an electronic device which supports those features and no others, and hooked the two ideas together with firmware and Java. It was all built to a price, and in that respect, it worked beautifully! - but it produced the variety which we see.

Move forward two years into the future, and you'll find feature phones with half a gigabyte of storage, much of which will be available for running software. You'll find users downloading, installing and testing applications which they never use again, or which they simply forget to delete, or even, don't realise they can delete.

And all this software will be expected to sit down inside the operating console of an utterly unfamiliar hardware platform, and know which buttons are safe to press, while other equally unprepared applications are blundering around in the machine room, pressing buttons more or less at random, and changing system settings to suit themselves.

In the PC world, the problem was solved (more or less) by the definition of a PC as "something running the IBM PC BIOS (basic input-output system) or a virtually indistinguishable copy of that BIOS." Lawsuits ensued, but by the time of the launch of the Mac, you could, really, write software for "the PC" and expect manufacturers to fall in line.

It's quite possible that by 2010, all mobile phones will be Series 60 clones. That would sort of solve the problem. At least, it might, if the Series 60 remained firmly defined as what it is today! - but of course, Symbian and Series 60 platforms will advance as the silicon inside them does. There will still be a need for relatively simple, lower-cost feature phones.

If they are all running a common OMA component model, all will be well. But who's going to bet their own money on that prediction?