More E

I continued my investigations into EFL, by browsing through some EWL documentation. EWL is a UI toolkit, built on top of the lower level parts of EFL. It's not exactly innovative (yay for innovation and marketing buzzwords). The API looks pretty much like a clone of GTK. I'm not complaining about that, GTK is a pretty nice toolkit to work with, but it's the kind of stuff that felt exciting 10 years ago. This is the most conservative part I've had a look at so far, in the EFL.

RasterMoko

It was recently announced that Rasterman is the new graphics architect on the OpenMoko project. People who have been around for a few years remember him as the guy behind the Enlightenment window manager, which was animated and glitzy already back in the days when fvwm was the standard window manager in Red Hat Linux. I had no idea that he had an interest in embedded systems, but it seems the EFL is aimed at embedded systems as much as the desktop. I decided to take a closer look.

There's a very nice introduction document, which explains what's so cool about EFL. I recognize the concepts that are touted as "unique" and "revolutionary" in EFL from TAT Cascades and Kastor, but the author of the document doesn't seem to be very interested in non-free software. All in all this stuff is really exciting, and I hope that I'll keep up my enthusiasm long enough to actually try out some stuff on the GP2x, because I'm a bit worried about performance. I got suspicious when I read that coordinates in edje are floating point values, and grepping the source code for "float" and "double" yielded quite a few hits. I'm guessing that the designers considered precision to be more important than frame rate, but I think that's a mistake if your target is embedded devices. However, I haven't run any benchmarks yet, so I shouldn't say too much.

Androidology

Now I've spent a few hours digging into the Android developer site. While I have some concerns, Artem makes a very good point: this is a platform that developers want to develop for. There's a public SDK a good 6 months or so before the first actual device will be released.

Sure, people seem to want to write code for Windows Mobile as well, but Steve Ballmer is like the only person in the whole world who would consider Windows Mobile a success. Symbian has 70% of the worldwide smartphone market, and that's starting to translate into a serious share of the mobile phone market as a whole. The most recent figures I saw are that 7% of the mobile phones being sold at the moment are running Symbian OS. Where does that leave Windows Mobile? 0.4% or so. About the same as Apple, that have been in this business for a couple of months now. Way to go, mr. Ballmer!

Speaking of the iPhone, there's a device that people want to write code for, and soon there will even be a public SDK. Of course, we don't know much about what sort of openness they'll provide yet. Sure, you might have the SDK, but there's no guarantee that you won't have to shell out a few thousand currency units to get you app signed, so that it can actually be installed.

There are some concerns about the Java emphasis of the Android platform. The problem I see with this is that there's no way to do a five minute port of your existing app if it's written in C. About performance, I don't think there's a reason to worry. You can write kick-ass games that run on VM:s, as long as they're done right. This was proved a long time ago with mophun, and when actual Android devices are on the market, most phones are going to have 3d hardware. For DSP stuff, there might be a problem, but it's not like there's a lot of DSP related apps around for the open platforms we have right now...

Android

The Android SDK is available for download. And in a dramatic break with tradition, you don't have to sign up to download the SDK. Just download it. Wow. This doesn't feel like the mobile phone business.

The insecure S60 firmware updater

It's nice to see that someone with an interest in practical security issues is doing stuff with Symbian platform security. Nokia's firmware update program for S60 handsets lets you install modified ROM images on (at least) some handsets. It seems the weakest link in this security system is very, very weak. Of course, hacking doesn't get really interesting until you can hack other people's devices, but there's a quite obvious attack vector here: what if you could get users to download your modified ROM images, instead of Nokia's? I'm no security expert, but thinking about this gives me a few ideas, that I might try out. I think Nokia should be happy that their devices aren't as popular with hackers as eg. the iPhone.

Insanely huge

Being from Sweden, I found the fact that a British smartphone site uses the Swedish tabloid Aftonbladet's site as a test site because it's "insanely huge", quite comical. Sure. Too bad the contents of the paper are even worse than their web design.

UIQ + Motorola

So Motorola bought 50% of UIQ from Sony Ericsson. I guess all we can say for certain is that Motorola is showing its dedication to the platform.

And of course, some people start speculating about a possible move of UIQ from Symbian to some other OS (like Linux). It's interesting how these speculations keep popping up again and again, even though the whole thing wouldn't just be (almost) impossible, but also completely pointless. You couldn't port UIQ or S60 to run on another OS, because Symbian is quite different from all other systems, and the UIQ and S60 code is filled with excentric Symbian idioms. Sure, you could spend a few years reimplementing the Symbian API:s on top of some other system, but the most important reason for moving away from Symbian would be to get rid of those API:s. The main problem with using Symbian isn't licensing fees, but that developing for it is such a nightmare.

Operators and applications

"Operators tend to have a very specific vision of the image they want to project through the third-party applications they sell, if they choose to sell applications at all. Most operators are still in a content 'stone age', offering mostly ring tones and games." (Here's a link to the interesting article.)

Yes, well, I think part of the problem is that it's a much more complex situation with applications than with games or ringtones. Games and ringtones are obvious customization items: we all have different tastes, so we want different ringtones. It's not a deficiency in the device that it's lacking the perfect ringtone for me, or a game to keep me occupied while I'm on the bus. Applications, however, is a different story. If you have to buy Handy Weather for your phone, the lack of a built-in weather app is quite obvious. It's even more obvious if the application you want to sell is a better replacement for an embedded app. Why wasn't the better app already installed when I bought my phone? Right, because the operator is only there to make money. It's all about appearance.

On a more technical level, applications feel more scary. A ringtone doesn't have any functionality, it's just a sound file. A game just draws stuff to the screen. At least that's what you'd believe if you're not an engineer. An application extends and alters the phone's behaviour. Who knows what it might do? Who knows how the users might react to these changes?

And then there's the infrastructure. That an application is Symbian Signed and can be installed without warnings on a phone doesn't mean that it's actually been tested on it. It's been tested on a compatible phone, but how compatible is compatible? How much testing does our operator have to do to feel confident enough about an app to start pushing it to their users?

Bugs and user errors

Some time ago someone who shall not be named blogged about a user error. In a certain popular IDE for a certain world-leading smartphone OS, there are two ways to shut down the emulator: you can do it from the IDE or by clicking the little red cross in the upper right corner of the emulator window. The above mentioned blogger had experienced problems when he used the little red cross: it'd take up to five minutes for the emulator to shut down properly. After contacting technical support, he was informed that a bug in the host operating system caused this, and that he should shut down the emulator from the IDE instead. He considered his previous way of doing it a user error.

Now, I know that programmers aren't always wizards of usability, but considering that a user error is like... stupid. I posted a comment where I compared it with a case that I considered to be analogous: let's say you have a document viewer, and you can scroll up and down either by using the cursor keys or by dragging a scrollbar, but if you use the keyboard, the app will crash at random now and then. Would you consider it a user error to use the keyboard to scroll in this case? Probably not. It's a bug.

The comments on that blog are checked by the blogger before they're actually displayed, and it seems my comment wasn't okay, which is why I'm writing about it here instead.

Oh, and by the way, do you know how sweet it is to do some Linux development after being stuck with Symbian for the last couple of years? Sweet as Arabian sweets, I tell ya!

Bad language

This is old, but I'm in a bit of a ranting mood, for some reason... I read some comment on a blog about the C language, and how it sucks for several reasons. Of course it sucks if you want a language with garbage collection and bounds-checking. If you want that you use some other language. If you want a portable assembler, you use C or C++. Or something similar, if you're feeling excentric. It's pretty simple: C sucks if you want Python. Python sucks if you want Java. Java sucks if you want Prolog. Prolog sucks if you want Intercal.

Nokia 6120 Classic

I got myself a new phone, a Nokia 6120 Classic. It seems to be a really nice phone. It's small (for a smartphone), it's cheap (not that I paid for mine, but anyway), it's 3G and it's fast (for an S60 device). It has a solid feel to it too, not the typical plastic feel that so many phones have, including most of Nokia's other S60 devices. It also doesn't look horrible, like some other phones. Too bad it doesn't come in spectacular colours (only black and white), because I would have loved a yellow one.

As a bonus, it comes with some code written by yours truly: the embedded game Marble Cannon runs on mophun, with my Symbian integration. It's a pretty nice game (haven't tried it before, Johan started coding it about the same time I quit my job at Synergenix), but maybe a bit too easy.

Open platforms

Some people don't think you should call the iPhone a smartphone, as it's not an open platform, while most people seem to agree that phones running SymbianOS are indeed smartphones. Well, at last the S60 and UIQ ones. The accepted distinction between open and non-open platforms seems to be that open platforms let you install third party native code. However, seeing as most open systems are more or less closed, as they only give third party developers access to a select subset of the system's API:s, it might be more useful to think of open vs. closed systems as a scale that ranges from completely closed to completely open.

A PC running an open source OS (or the Neo 1973 smartphone) is about as open a platform as you'll find, while a wristwatch is a completely closed system. Between these you have systems like the iPhone, that lets you install widgets, with little access to system functions, feature phones that let you install Java midlets and typical smartphones, that let you install native code apps, but don't give you access to the full set of system API:s, and won't let you replace system components.

The iPhone is less open than a typical feature phone, but it's also more "smart" than those, as it's running a real OS, just like smartphones. This just shows that categories like feature phones and smartphones are too simplistic. It was a good idea to use these categories 5 years ago, when open phones was something new and exciting.

Web 2.0 vs. open source

I read this article over at AllAboutSymbian some time ago. It seems 3 want their users to create their new portal, web 2.0-stylee. In a corporate context, this might sound like a superb idea: someone else does the work, you cash in. It's like with open source around 2000: there was a wide-spread perception that you could just upload your code to sourceforge, and thousands of nerds around the world would start doing the work for you, Linux-style, or Mozilla-style. However, those nerds need some sort of incentive. It just won't work for any project. It works exceptionally well for cool projects like the Linux kernel, but might not work as well for something completely uncool, like an office suite.

Web sites with user contributed content work great if the users feel that it's a good service, ie. if it's fun or useful. Adding links to mobile sites to 3's mobile portal probably isn't much fun. I know I couldn't be bothered.

Hacked to pieces

Even the hackers fell for the hype and got themselves iPhones, and are now busy getting different kinds of code to run on it. Like hello world. Like remote exploits that let you run custom code as root. It seems Apple didn't pay much attention to security at all. I'm sure they saw this coming, but with their limited experience in the field, they didn't get the maths right: 1 (people like to hack their devices, like Apple TV and the iPods) + 1 (the iPhone has lots of wonderful networking features) + 1 (an iPhone will probably contain some sensitive information) = 3 (legitimate users might actually suffer).

It'd be interesting to see how well a Symbian device would stand the test, but I guess they aren't interesting enough to attract competent people like those responsible for the above mentioned hacks, but some things are obviously done much better in Symbian than in MacOS. Like the web browser doesn't run with full privileges. Like the web browser probably can't even access your text messages. Basically, Symbian OS 9 is built with security in mind, like a smartphone should be these days. The iPhone is a smartphone (as in a very smart phone, never mind how people might define it), but it seems to be designed on the assumption that if you're not officially allowed to run 3rd party native code, you won't. Now there's a mistake.

(I don't know enough about the security features of eg. Windows Mobile to talk about that.)

A platform security design miss

Designing software is difficult, which is why the waterfall model is such a joke. You don't get the design right the first time. If you ever get it right, it's after it's been used for real, and you've corrected the worst mistakes. (There are exceptions, where the original design happens to be so good that it lasts. Despite what some people think about the standard C library (and the language itself) nowadays, it was created around 1970, and it still makes sense. You don't see that kind of stuff often. The details that have changed aren't really important.)

I've been quite impressed with the design of Symbian platform security. It works. It's pretty sane. It's conceptually quite simple. Of course, it's horribly complicated to learn how to live with it in practice, but on a technical level, it's good. (The infrastructure around it isn't very good, but we'll ignore that for now.) However, there are some mistakes in it. One is the one making hacks such as this one necessary. When you install an app on the external memory card, a checksum of the executables are stored on the internal one, as that one is more safe (it can't be removed and edited outside the phone, at least not easily). This leads to an interesting problem, which was probably very hard to foresee: if you format the internal memory card, you can't run the apps installed on the memory card anymore, as the checksums are gone.

You might argue that you shouldn't have to format the memory card on a working system. Sure, but it's not a good idea to design around the assumption that every system will be perfect. Smartphones are far from perfect. The software on them is very complex, and there will be bugs. I have to format the internal memory card on my phone now and then, because there's some sort of leak which means that it'll be filled up, and there's not much I can do about that, as I can't clean stuff up manually, as platform security prevents me from tampering with most of the contents. However, the same problem would occur if a badly behaved app was installed on the phone and started filling up the memory card, so it could happen on a perfectly working system as well.

Quality software

People like to say things like "and as Symbian is an open system, there's lots of third party apps available". Sure, there are a number of 3rd party apps out there, but how good are they? I haven't really sampled all that many recently, and what I've seen has been disappointing. It's nice to see that AllAboutSymbian are commenting on this as well. It's not like the stuff pointed out in that article are hard to fix, but face it, there's not much available, and what's out there is often quite bad.

This isn't the usual rant topic ("programming for Symbian sucks"). It's about sloppy developers. I hope people take this seriously, because if most of the 3rd party software sucks, there's not much point in having an open platform, right? And if the only advantage of having an open platform is taken away, we might as well have closed platforms. And that like... sucks.

Prada disappointment

I got to play around with the LG Prada phone a bit today, and it was a very disappointing experience. I had expected it to be slick and designish, but while the design of the actual phone was quite nice, albeit very conservative, the user interface was horrible. It's implemented using FlashLite, a piece of technology that I haven't really bothered to have a closer look at before, and after seeing the Prada phone in action I just want to forget about it.

Some time ago I read a blog posting about FlashLite, by someone working at Adobe. He wrote something like "on a regular phone you'll achieve a framerate of 6-7fps", which I wrote off as a joke. But he wasn't joking. It really is that slow! Actually, the "animations" I saw on the Prada phone looked more like slideshows.

I work at TAT (yes, I agree, the homepage is quite ugly), where we develop stuff like Kastor, a graphics engine, and Cascades, a UI toolkit. Currently, we're working with four out of the five biggest OEM:s (although only Samsung and Sony/Ericsson are offical so far, you'll hear about the others as soon as I'm allowed to speak of them, ie. when they have products with our code in them on the market). Our solutions are so vastly superior to FlashLite that it's a shame to even call Adobe a competitor. I've been hearing that we're really good at what we're doing ever since I stated working at TAT, and I've sure noticed that my co-workers are competent, but I had no idea that we were so much greater than the so called competition.

If you can't get a framerate of at least 15fps, you're not even in the game. All that Adobe can hope for is that Moore's law will keep up its promise, that all phones will soon have hardware accelerated graphics or whatever. Until then, FlashLite is a joke. And it's still a joke if you need workstation type hardware to run their software. Sorry. If stuff like this is acceptable in the mobile phone business, I can finally understand why people are ranting and raving about the iPhone. I just hope I'll get to play with one of those one of these days. I'm sure I won't be as disappointed as I was by the Prada UI.

AIUI

It's interesting how hard it is to design user interfaces. Even if you have usability designers involved in the process, even if you go through lots of testing, user interfaces always seem to excel at annoying the users. I've talked before about confirmation dialogs, and well, I just can't stop being annoyed by them, so here we go again...

Today I started writing an SMS, then realized that I should call this person instead, so after writing 2 or 3 letters, I pressed Cancel. Of course the phone has to pop up a dialog, asking me if I'd like to save what I've written so far as a draft. No, thank you, that wouldn't be of much help, actually it wouldn't make sense at all. But the code in the messaging application has registered input, and so has to pop up that dialog. Now, how hard would it have been to introduce some arbitrary limit on the minimum number of letters typed, before popping up that dialog if Cancel is pressed? A few lines of code should do it.

Of course, doing this might seem a bit dangerous. Maybe the user is counting on getting that popup when pressing Cancel. Maybe some users like to save lots of 2-3 letter drafts, to reuse later. Don't mind the fact that opening it would take longer than re-typing those 2 or 3 letters. Well, I don't think it matters. More users are likely to be annoyed by the confirmation dialog than by losing a few words of text.

Or, well, what do I know?

The final chapter. And the first one.

Sony/Ericsson announced that they've now shipped the final firmware for the P990, the M600 and the W950. It seems there are still quite a lot of issues, and parts of the smartphone fanatics crowd are furious. I can understand them, because they've paid for expensive devices, which are now pretty much obsolete.

But in a way, isn't it better to move on and forget about this whole disaster? Sometimes you buy things that aren't as good as you expected. Sony/Ericsson probably made more money from these phones than they're losing from bad publicity. And I'm sure they've learnt their lesson. Don't try to integrate a major new OS version along with several new networking technologies in one device. It's too complicated. Software engineering really isn't that advanced. There's a limit to how much complexity it can handle.

And tomorrow the iPhone will start selling in the USA. Initial reviews seem to indicate that it lives up to the hype, but we'll see how well it's holding up in the real world. It seems Apple did the right thing, despite the fact that this is their first phone. They chose not to include 3g or MMS. You can't even use the camera to record videos. If they'd tried to add as much nerd-magnet technology as in the N95, they might have failed spectacularly. With that much hype, lots of people were probably hoping that it would.

The Symbian OS Architecture Sourcebook by Ben Morris

As a Symbian developer, you're locked out from most of the system-level information, which is why it's a good thing that books like this one, Symbian OS Internals and Symbian OS Platform Security are published. Just like those other books, this one contains some very good information, and is a very frustrating read because of all the omissions and/or the weird structure.

The author of this book is trying to do two things with this book: to provide a description of the high-level design of the OS and to tell the history of the development of it. This sounds manageble, but it leads to a very fragmented book. The most interesting stuff is contained in the first part, which is mostly historical. Here we get explanations for stuff like descriptors and MMP files (they were borrowed from VMS), and gain an understanding on why Symbian OS is such a weird system (most of the architects just don't seem to know much about computer systems, so they invented everything as they went along).

The second part is a description of the different parts of the system. This one probably isn't meant to be read straight through, and I found myself skipping quite a few pages. This section isn't boring just because of the topic, but mostly, I think, because it's so badly written. Everything is repeated a great number of times, which gives the book a distinctly American feel, although (I believe) the author is British.

The third part consists of case studies, and is more similar to the first part. There's some interesting history here, but much of this stuff is repeated from the first part, and reading it for the second time doesn't exactly make it more interesting.

The reference in the appendix feels quite unnecessary. It's just a listing of components, with some basic facts, such as their names, build file location, which OS releases they're included in and one line descriptions. I don't quite get the point of including this part in the book, in the Internet age. This would have made much more sense in electronic form, where it can be easily searched, and much more information could have been included.

One theme that runs through the whole book is what I'd like to describe as the effects of the Symbian Reality Distortion Field. Steve Jobs might have made it famous, but Symbian Ltd. are without a doubt the masters of creative bending of the truth. Sure, we've heard most of this stuff before, but anyway, here are a few examples: Descriptors, the first thing most developers will mention when ranting about how weird and difficult Symbian is to program for, is described as a gift from god. Active objects are described as the best possible event handling mechanism, despite the headaches it gives developers. I suppose the author hasn't bothered to study alternative solutions, as the only alternative he mentions is the archaic event loop. The praise of the horrible UI framework feels more like an insult than anything else, and claiming that "the system has been optimized to produce fast graphics on low-power devices" is just crazy. Anyone who's tried using the Symbian graphics routines know that that's just not true. The only way to get decent graphics performance out of a Symbian device is to use Direct Screen Access, which bypasses the system's drawing code.

On a more positive note, the description of the system design gives me the impression that a lot of good design decisions have been made on a high level. Unfortunately for the developer, on the API level everything seems to have gone wrong. The explanation for this seems to be that the designers were learning C++ as they were constructing the API:s.

All in all, the first part makes the book worth reading, and the other parts provide some additional insights. Again, it's a book that gives you information that you can't find anywhere else, unless you're a Symbian (or partner) employee, and for that reason it's worth reading. However, the evangelism is quite offensive, so it's not an easy read if you've just eaten.

Faking the iOrgasms

I guess you've all seen the iPhone commercials by now. The focus on the cool UI is strong, but it makes me wonder how slick it really is. I don't doubt that the animations will be smooth, but I have my doubts about that photo browser, or more specifically, the speed with which it manages to load a dozen photos from disk. As far as I know, the iPhone uses flash memory, not a hard drive. Flash memory is slow. Noticably slow. As in: you can't load ten photos from it in the time it takes to display a flashy fade effect.

But I guess I shouldn't complain. This is what advertising is about. But it makes me wonder how much else is faked.

A real trojan for S60 phones

"Finally" there's a piece of malware for Symbian phones that actually does damage. Of course, there's not much risk of getting infected by it: it's a simple trojan, uploaded to a file sharing site, posing as a utility. Once installed, it'll send SMS messages to a premium rate number, effectively adding about $7 to your phone bill. The descriptions of it seem to suggest that it only sends one SMS per infected phone, which makes me think it's more of a proof of concept implementation. The program runs on S60 1st and 2nd edition phones.

There shouldn't be any problems porting this thing to 3rd edition, which is interesting, considering how much pain Symbian and partners are willing to inflict on developers for the sake of security. This app doesn't need any restricted privileges and would not need to be Symbian Signed. Sure, the user gets an extra warning at install time, but people who install 3rd party software on their Symbian 9 phones are used to that, and will just press OK. Autostarting the app might be a problem, but that shouldn't be an issue: the user is obviously going to start the app after installing it, at which point it can start sending its premium rate messages. A clever coder would of course spawn a background process that keeps sending new messages continuously.

But well, writing software that does damage after the user has manually installed it is never going to be difficult. Writing code that could install itself without user interaction would be a real challenge.

The sun

It seems I missed this while I was busy getting jetlagged. Sun are porting their recently acquired SavaJe platform to run on Linux, and building a complete phone platform to be licensed to phone manufacturers. They don't have any licensees yet, and it'll be interesting to see if they'll manage to get anywhere in a field of business where Microsoft have failed quite spectacularly. I guess Sun have a greater chance of getting this platform out there than SavaJe did, with their resources, but at the same time, it's obvious that you can't just throw money at something and expect it to be a hit.

The linked article says that the software will only be distributed in binary form, to keep compatibility between handsets. I'm not sure if phone manufacturers and operators will be too happy about that. With a well designed system, there might be enough hooks in there to make differentiation possible, but there's only so much you can do without the source code. I think one problem with Windows Mobile is that it's so heavily branded as a product in itself. Handset manufacturers and operators want it to look like the whole package is their own product. This might turn into a problem for Sun, and they might have to reconsider the binary distribution model. Compatibility is nice, but I think this is mostly a concern for them, not for their customers or the end users. This is not the desktop or server market, end users aren't interested in compatibility, most of them don't even know that they can install software on their phones.

Again, it's nice to see some new products in this field. We already know that it's a very tough market: S60 and UIQ still don't have many licensees outside of Nokia and Sony/Ericsson. What makes Sun think that they'll succeed? Using a whole new system is a very big decision, as it's a huge effort to get to understand it, train people to work with it etc.

(And finally, the linked article is full of these naive iPhone references we've seen in almost every phone related article in the press since it was announced. Please, stop it already, you're just making yourself look clueless.)

Big in Japan

A couple of days ago I got home from Japan. From a mobile perspective, Japan is very interesting. It's about as different from the rest of the world as USA. They just do everything their own way. I'm not going to try to analyze that stuff, though, as I believe that there are others who can do that much better than me. I didn't exactly spend much time studying mobile phone usage when I was there, instead I concentrated on sightseeing and drinking beer, so I'll just report on some observations I made:

One thing that I've talked about before is how colourful and beautiful the phones are. The Japanese also seem to use them a lot. And it's not like they mainly use them for placing calls. I'm not exactly sure what they use them for, but my brother's wife told me that they don't use SMS much in Japan. Instead they use email, but not with their regular email account, but with another address that's specific to the phone. So it's the same as SMS, except that there's no arbitrary limit on the length of messages. I guess the disadvantage is that you actually have to know someone's email address to be able to send an email, while with SMS you just need to know the phone number.

Then there's all the whimsical stuff about the straps, emoticons etc., but I'm not going to go into that, but it fits in well with Japanes pop culture, I guess.

User friendly

It's interesting how some people can introduce features that's supposed to help make a product more user friendly, without using their brains at all. You'd expect big companies like Nokia to think about these things, because phones should be easy to use. And it seems they're at least trying, there are some definite improvements in S60 3.2 (eg. there's always an option to open the task swapper from the options menu, so now users will actually learn that the task swapper exists). But they have to work harder than they've been doing so far.

One usability feature that everyone knows has a tendency to just get annoying if overused is confirmation dialogs, like the one that pops up everytime you try to delete a file in Windows. To me this is just an annoyance, and I wish there was a way to turn it off. Maybe there is, I'm no Windows expert.

S60 is complex enough as it is, and very little has been done about that during the last 5 years. But they just keep going. After all, these phones are selling like crazy, and there's no need to change a winning concept.

But the file deletion confirmation dialog at least makes some sort of sense: it protects the user from accidentally erasing important data. But the people who wrote the music player in S60 probably didn't think "we need to protect the user". I think they thought "we need confirmation dialogs". Then they sat around a while, and then they thought "lots of them". As I said, at least you can make an argument in favour of having a confirmation dialog for file deletion, but for deleting a song from a playlist? That makes no sense at all. It's not like the song itself is deleted, it's just removed from a playlist. If you accidentally remove a song from a playlist, you just add it back. Or you don't, as it probably doesn't matter that much.

It's a good thing that these people didn't design the phone application. I mean, there's a risk that you accidentally hang up during a call, so there should be a confirmation dialog. And there's a risk that you dial someone by mistake, so there should be a confirmation dialog. And there's a risk that you say something stupid while talking on the phone, so there should be a confirmation dialog every time you say something.

My development environment, my arch enemies

It's an arduous task, doing Symbian development. You don't just have to fight with horrible API:s. You also have to use tools that you learn to hate. I like my job. I like the people who work there. I like the stuff I do. But I really don't like the fact that my arch enemies live in my computer. It's not like it's an even fight either, there are four of them and just one of me. My arch enemies are:

Codewarrior. I use either the pro or the OEM edition, can't remember which one. These are the editions that professionals use. Poor professionals. I'm not going to get into the quirky UI, the lack of bld.inf support and stuff like that. It's the bugs that bother me the most. Like the sudden crashes. And the mystical bug that's called "Symbolics window" (there's a discussion about this over at Forum Nokia, but the search function there is another enemy of mine, so I couldn't find it), that slows things down so that stopping at a breakpoint can take up to a minute. I kid you not, that's 60 seconds. It sure steals my time, this tool. I can't even begin to understand how it can take Codewarrior a minute or more to import an MMP file. These are simple text files that describe a project: basically the source files and the libraries to link. Importing one of these can take minutes. I don't think any software developer with half a brain would argue that this makes any sense.

PGP Desktop. Built on top of the stable, standardized and generally wondered pgp code, this is a horror in software form. It's not just the instability, the way it can suddenly refuse to unmount a disk, or whatever. It's mostly the fact that it's completely braindead. There's no way to just assign a drive letter (2007 and we still have drive letters, great work there, Bill!) to a specific PGP disk. Instead it'll always default to the first free one. Every time I mount one of these suckers, and I usually have about a handful of them, I have to choose where to mount it. This isn't just inconvenient, it means I have to remember where I want it mounted, so that Codewarrior won't piss me in the face if I choose the wrong drive letter and then try to open a workspace. You get the picture.

Epoc. The Symbian OS "emulator" (it's not an emulator, it doesn't even run native code, you have to build x86 code for this "emulator"). This one has a lot in common with Codewarrior, which is probably why they work so well together (yes, that's irony). It can take minutes just to start it (yes, I have a fast CPU and 2 gigs of RAM). It looks up for no reason. Bugs in the code you're debugging makes the whole "emulator" go down in flames. And of course the actual emulation isn't good enough to be trusted.

Windows XP. Yes, the foundation of shit on top of which all of the above shitbuildings are based. There's no end to the misery that this sucker can bring to you. I mentioned drive letters above. That's not even funny anymore. The instability, the bad temper, the reek of bad design that sometimes makes me want to throw up all over my computer. Oh well, you probably know already, so there's no point in me going on about it.

Oh well, I'm on vacation for two weeks now. I know my arch enemies won't follow me to Japan (going there on Monday). Or well, they just might... They're not to be trusted.

[np: Napalm Death's second album]

Innovation

No one likes marketing talk, but it's sort of interesting what's happened to the word "innovation" lately. In the IT business, it doesn't mean anything anymore. Or well, it means something. It means doing something. Implementing something. Or whatever. Read this news piece and try to find any connection between the usage of the word "innovation" and any actual innovation. I'm not the one to start any senseless Microsoft bashing, but it might be their fault to a large degree, considering the "freedom to innovate" campaign and all that bullshit.

Scifi ninja phones

In a couple of weeks I'm going to Japan to visit my older brother and his wife. How fitting that NTT Docomo just announced some new phones, including three that run Symbian. I look at these pictures, close my eyes and float away into dreams of pink, yellow and green robots, blowing plastic bubbles, filled with some kind of incomprehensible magic electronic fluid. I'm absolutely convinced that if the people who designed these things are from earth, they must be from the future. Just compare these beautiful objects with the clunky things that Nokia call "multimedia computers". People are enthusiastic about the iPhone and the Prada phone, but these Japanese works of wonder make those devices look like they run on gasoline.

Letter from America

Okay, after reading another excellent blog post by Tomi Ahonen, I realized why push email and the Blackberry are so popular in North America: they're using it as a replacement for SMS, which they still haven't understood. I'd heard of how the American operators had sabotaged SMS, but I thought those problems had been sorted out and SMS had caught on like it has here by now. It seems it hasn't, although the service actually works now.

But there's no reason for me to keep going on about this. Read Tomi's post, it has lots of interesting info.

[np: Letter from America by Proclaimers]

Software quality

The P990 has been around for quite some time now, but just a few weeks ago the firmware upgrade that actually makes it reasonably stable was released. Or so I'm told, I'm happy about the fact that I don't have a P990. The P990 probably wasn't a very good idea from the start: too many new features in one single device is never a good idea, and as a consequence it started selling much later than originally planned, and was buggy in a way that makes Windows 95 look like a mature product (well, that might be an exaggeration...).

The P990 might be a bit worse than other smartphones, but it's not exceptional. To differentiate your phones from the competitors' products, you need new features. If you spend two extra months testing and fixing, one of the competitors will release a phone with the same new features, which means customers who want those specific features will buy that one instead.

Quality doesn't mean the same thing in commercial products as it does in non-commercial ones. I have a background in free software, and getting to terms with "quality" in the commercial sense is a bit hard. A defect is a problem if it has negative economic consequences, ie. if it's cheaper to fix it than to handle it with support, lies ("it's a feature!") or just ignoring the complaints.

The result of this interesting view on quality and the race for new features is that cutting edge phones are never stable. But smartphone customers don't want last year's products, so I guess we'll have to live with our buggy phones. At least you don't have to go to a service center to upgrade your firmware anymore...

Widgets in S60 and new devices

With S60 3.2 you'll be able to to go "beyond web browsing with widgets". People react to this in different ways. I can't say I'm all that interested, but widgets might actually be more useful on mobile devices, as it's quite fiddly to search the web with their limited input capabilities.

I'm a bit old-fashioned, so I'm more interested in new S60 devices. And Linux ones. And less impressed with Intel's new concept of a "new" device category, somewhat more advanced than a surfboard like the N800 and somewhat less so than a UMPC.

The S60 Quality Assurance book

"S60 Smartphone Quality Assurance. A Guide for Mobile Engineers and Developers" by Saila Laitinen is not a good book. It's not even a finished product. Ironically, no quality assurance process at all seems to have been applied. Typos, spelling errors and grammatical errors make me lose concentration when reading, and they're all over this book. As the author is not a native English speaker, it's unbelievable that it hasn't even been proofread. The structure of the book is also quite strange: it starts with a few chapters on S60 phone development before it goes on with the main part, which is mostly about testing, and closes with a final chapter about the build environment. The last chapter quite obviously belongs to the first part. It might have been intended as an appendix, but doesn't read like one. The book also lacks a conclusion or summary. It just ends.

On the positive side, the actual information provided is quite interesting. The introductory chapters, on developing a smartphone, are good, but if you're interested in that, you're much better off reading "Symbian for Software Leaders" by David Wood. The main part, on quality assurance, contains a lot of good information, both general and Symbian/S60 specific. Unfortunately there doesn't seem to be a clear focus on the level of detail. Some parts read almost like a reference, eg. the lists of required material for testing specific applications in a phone, while the rest are much less detailed.

There are lots of other problems as well. Most of them aren't the author's fault. The problem seems to be that she did all the work, and the publisher did nothing. If a good editor had been involved in the project, this book would have been much better. Obviously, the only editor that was involved here was the text editor used to type the text.

SavaJe

In the news: Sun acquires SavaJe Technologies, whose product is a Java-based embedded OS. The combination of the words "Java" and "mobile" normally makes my stomach turn, but SavaJe Mobile Platform is supposed to have better performance than regular mobile Java implementations, as the whole OS is built around the Java VM. The Java API is the native API. It'd be interesting to actually try out a phone running SavaJe OS and see what it can do, but unfortunately there doesn't seem to be more than one handset that uses it at the moment. This could potentially be a competitor for Symbian, Linux etc., but in this day and age I think it might be a bit problematic to persuade phone manufacturers to try out yet another OS. But if it performs as well as they say, developing the whole system in Java might make the whole process easier. And they support JSR-209 (Swing), which almost makes mobile Java seem like a good idea. Those who have written UI:s in both AWT and Swing know what I'm talking about.

Now I'm just wondering when there will be a Flash Lite OS. :)

Dis da Symbian blog

Well, I expected it to be mostly about Symbian stuff, anyway, as that's what I work with, but it seems Linux is taking over more and more, not just in the mobile world, but also on this blog. The latest news is that Palm are launching their own proprietary Linux based platform.

As for the Symbian news, today I received my copy of S60 Smartphone Quality Assurance (thank you, Forum Nokia!). I'll get back with a review as soon as I've read it.

Surfin' Bird

I finally got around to trying out the wlan on the N93. I took the train from Stockholm to Malmö, which takes four and a half hours, and SJ are kind enough to offer free wlan access (and free coffee) to those of us buy first class tickets.

Getting connected isn't a problem. Just login with the code on the ticket and start surfing. The connection feels pretty slow, but it did when I connected with the laptop too, so this doesn't have anything to do with the N93. Rendering big pages is also pretty slow, but that's to be expected, as I didn't focus on mobile optimized sites.

The browser is really good, except for some stability problems. It crashed on me twice: once when I was trying to login to my gmail account, and again when I logged out. My frequent changes of screen orientation (reading is more comfortable in landscape mode, but typing text is much easier in portrait mode) also seemed to make it a bit confused now and then. Another problem was that I couldn't figure out how to open new windows, although it happily opened a new window when I logged in on the SJ site.

All in all it was a positive experience, and I'll definitely bring the N93 the next time I'm taking a long train trip. It's not like I'm going to bring my 3kg laptop just to surf for a few hours, but the 200g N93 isn't a problem.

Linux on mobile and on the desktop

ABI Research has released a new report called "Mobile Linux", where they, unsurprisingly, predict that Linux is going to grow immensely in the mobile space during the next five years. Linux will be used both in smartphones and as an RTOS replacement in mid-tier phones.

The evolution of Linux on mobile devices seems to follow the same path as Linux on the desktop: it started out fragmented, with lots of separate bits and pieces, but is now in the phase where these components are either being replaced or compiled into complete solutions, just like gtk/gnome and qt/kde have unified the X desktop. Of course, there are still two different desktop environments, but I'm not sure if that's a disadvantage. The competition should keep the developers of the respective systems on their toes. It seems likely that there will be a similar division on the mobile side, between gtk and qt(optia), and possibly also some proprietary alternatives. With projects such as OpenMoko, there's no need for a phone manufacturer to build everything from scratch anymore. The basic components, including apps, will be there, and all they'll have to do is to customize the platform and add the stuff that makes their devices different from the competitors' offerings.

Le phone de flickr

I found this kind of interesting. There's supposed to be at least a million 3250's out there, so how come not more pictures on flickr are taken with it? And how many millions of N73's are out there? The mind boggles (my mind, that is, you can just relax now).

Symbian OS 9.5

Today version 9.5 of Symbian OS was announced. Among other things, it features some serious performance improvements (demand paging, file caching, RAM defragmentation). Especially demand paging sounds sweet, as it'll speed up application startup a lot. This is sorely needed in Symbian, because it often feels pretty sluggish. Sure, that's the price you have to pay to run such an advanced system on limited hardware, but I know I'm not the only one who feels that the hardware can't be blamed for all the perceived slowness of the devices.

However, a faster OS might serve as an excuse for the phone manufactures to cut down on the hardware, effectively giving the same performance as current models. Another alternative is that they'll add more features and bloat, which still seems to be the main priority of the phone manufacturers (at least when it comes to smartphones), although the iPhone has at least shifted that focus a bit towards user interfaces.

The Motorola news

So Motorola are losing money, and decided, among other things, to concentrate on Linux from now on. Their proprietary RTOS P2K will be no more. I haven't managed to pick up any info on whether this means that they're going to drop Symbian and Windows Mobile as well, but I assume they will. Working with just one platform, both for smartphones and feature phones, definitely makes sense.

People can keep going on about how immature, unfocused and untried Linux on mobile devices is, but its 40-50% market shares in the Japanese and Chinese smartphone markets should make it obvious that that's just not true. Japan and China aren't exactly second league when it comes to hitech stuff. This Motorola story looks like just another piece of evidence that Linux will be the dominant OS on phones in a few years. Both Symbian and Windows Mobile have their strong points, but technologically Symbian is quite horrible, and Microsoft keep failing in their attempts to gain market shares outside of North America.

Phones and the computer security business

This news item is in Swedish, but here's a short summary: security expert Eugene Kaspersky is worried about security in feature phones, because they're typically not multitasking, so you can't run anti-virus software on them while other apps are running. Smartphones are better off though, because they're pretty much like regular PC:s, with real operating systems, which means virus protection software will work fine.

Doesn't that sound a bit like mr. Kaspersky is biased in favour of platforms that can make him money? If he was really worried about security, I think he'd prefer feature phones, because it's much easier to keep simple systems secure. But of course, if you're doing what companies like Kaspersky Labs do, make money from helping protect buggy systems, you have every reason to want every system in the world to put on as much fat as possible.

Metaphors and assumptions

Desktop mp3 players aren't what they used to be. These days they all insist on taking care of your music collection for you, index it and make it searchable. This has its advantages, but I can find my way around my own music collection, thank you, and I prefer to be able to just play a file, without having to insert it into a database before the player can find it.

The same goes for the mp3 player on my phone (Nokia 3250). It insists on building a "music library" from the music it can find. The library metaphor is pretty weird. My memory card won't fit more than a few albums, so it's way too small to work as a library, it's more like a small bag which can be used to carry around a few books. This means that I tend to change the music on the phone quite often, and every time I have to wait for the music player to update its "library". That's just annoying. Pretty much as if the bag wouldn't let me just pick up a book and read it, but required me to go several levels down into a menu system to get to it.

The creators of the S60 music player obviously assume that you're going to keep your whole music collection on a micro-SD card. If you don't use it that way, the library concept just stands in the way of your music listening.

The revenge of the CLI?

David Beers is enthusiastic about the possibility of controlling mobile devices with a command-line interface. I know what you think - the same I did. You can't possible be expected to learn a cryptic new language to control your telephone! However, his proposal isn't completely off the wall, and he managed to emphasize a few of the great advantages of CLI:s.

First of all, you save time as you don't need as many clicks or button presses to run a command from a powerful CLI as you do from a desktop type user interface. The examples in the above mentioned post uses auto-completion quite aggressively, and when it works well, it requires very few keypresses to make a call, schedule a meeting etc. It should be noted that this isn't about just porting bash to S60. That wouldn't help anyone, as typing is way too hard to use something like that. What's required is a language that's designed to control a phone.

Second, CLI:s don't require diving into data silos (applications) in the same way as you do in GUI:s. To write a message on a regular phone, you have to open the messaging application (click, click), find the recipient(s) in the contacts database (click, click, ..., click), write the message (that'd be the same, regardless of the UI) and finally exit the messaging application (click, click). With a CLI, the whole system is accessible from the same place.

I think a concept like this would require some serious thinking before it has any chance of success. The phone has to be usable by anyone as soon as it's switched on. I don't think a helpful piece of advice, such as "Press 'h' for help" is going to solve that problem. There's no point in developing the next generation UI if it'll only be suitable for nerds like me.

(Background: I grew up with the C-64 (load "file",8,1 ... run), and thought the Amiga was a bit awkward to use at first, as it threw you into a weird landscape of icons and menus intead of BASIC 2.0. I later got used to it, but I still prefer the command-line in Linux, and can't live without Cygwin when I have to use Windows. So I prefer CLI:s, but I can see why not everyone does, and sometimes a GUI really helps.)

N-Gage again

However stupid it might be to keep the N-Gage brand, which I "discussed" yesterday, this blog isn't focused on marketing, but on technology. Therefore it's nice to see some talk about the new N-Gage platform from a technological perspective. Finally we get some facts, although they may not be as detailed as we'd wish for.

What's said in this interview gives me some seriously good vibes. Open C and custom API:s are used to give the developers a much more convenient platform to work with than the regular Symbian framework. It's really nice to see Nokia people admit that Symbian is a horrible platform to write code for. It seems the games team are also having some positive influences on hardware design within Nokia, although it remains to be seen what consequences that will have in practice.

One thing I've been wondering about is how they're going to tackle the problem that some devices will have 3d hardware, while others won't. I'm assuming that you'll be able to run N-Gage games on non-accelerated phones as well. I suppose they'll try the usual solutions: provide both 2d and 3d versions of the same games, or make the real high-end games available in heavily stripped down software 3d versions for non-accelerated devices, or just require a more powerful handset for some games. However, the last option will seriously limit the market for some games, until cheaper devices will also be equipped with 3d cards.

No matter what happens, I'm pretty sure we're going to see some mobile games that will put everything that's available today to shame. With 3d hardware and TV-out (eg. on the N93) mobile phones could soon be competing with "real" consoles, like the PSP and DS. (Yes yes, I know, mobile phones suck as gaming consoles, but that might actually change some day...)

.Net compact framework for S60

Red Five Labs announced that a first public beta release of their .Net compact framework for S60 is available for download. So, another app framework for S60 phones, I guess we should all be happy about that. Oh well, I don't know. According to a collegue, the performance of .Net on Windows Mobile devices is comparable to Java, and I've never been a fan of mobile Java. But I guess the whole point of having .Net for S60 is that you can get your Windows Mobile software running on S60 devices without having to spend much effort porting them. For other apps I still see very little reason to run anything but native code on open platforms. The performance is dodgy as it is with native code, and inserting a virtual machine between your app and the hardware doesn't help.

Don't get me wrong, I have nothing against interpreters/VM:s in general, but in most cases the performance and overall user experience just isn't worth it. There are exceptions, such as the mophun gaming middleware, but unlike most other virtual machines, that one actually gives near native performance. Other VM:s, in combination with 3D hardware, might also be suitable for games and multimedia, but besides that, solutions like Java, .Net and Python don't have much use except as toys or prototyping tools.

The N-Gage brand again

I found this via All About Symbian. So it seems Nokia decided to keep the N-Gage brand for their new gaming platform. According to Antoine Doumenc, head of global sales for games at Nokia:

We are going to push the platform, absolutely. To look at another company - if you consider the Nike brand, it has a value whereby you know if you walk into a Nike store you're going to get a product of a high quality. It's the same thing here. With N-Gage we want to do the same thing for consumers. When they hear the N-Gage brand they know they'll be getting a valuable experience.

Come on now, wouldn't it have been a smart move to come up with a new name? People are still making jokes about the original N-Gage. Sidetalking, anyone? Having to remove the battery to switch games? People don't think "quality" if you mention N-Gage. The old N-Gage doesn't have much in common with the new platform anyway. There won't be a new N-Gage device, so the point of keeping the name is way beyond me. It seems they're doing their best to fail again.

The platform security book

Some time ago I read Symbian OS Platform Security. I got it mostly because I wanted some answers to my questions on why platform security is implemented the way it is. The book was quite different to what I was hoping for, though.

I had expected it to be mostly theoretical, explaining the concepts in depth. There's a bit of explaining in it, but not nearly as much as I had expected. Instead most of the book is about implementing platform security in apps. Don't get me wrong, there's nothing wrong with those parts, the chapters on writing secure apps, servers, plugins etc. are quite excellent, they just didn't answer my questions.

So I still wonder why they chose to unnecessarily limit access to parts of the file system (eg. why isn't /sys/bin readable? why can't you list the files in /private?). That just reeks of security by default ("we're not sure if this could be a threat, but we'll limit access anyway, just in case"). And why isn't there a mechanism for apps to share protected files? Sure, it's obvious that adding permissions to the file system would have made things more complicated, but instead the people who write the apps have to write their own servers just to share files between apps that trust each other, with all the security implications that comes with it.

As always, when it comes to books from Symbian Press, this one contains a wealth of information on stuff that isn't available anywhere else, and for that reason it's worth reading. Still, I can't help feeling disappointed...

OpenMoko info

If you're the least interested in mobile phone development, you want to check out openmoko.org. Subversion access, mailing list archives, a wiki and developer blogs, what more could you ask for? Having this sort of detailed insight into the development of a phone platform sure is sweet. I hope I'll find the time to have a go at writing some code for this project.

Totally rad

An early version om SymRAD was released a few days ago. It's a RAD tool for Symbian phones (Series 80, S60 3.x and UIQ 3.x), where you define your UI in XML and code application logic in javascript. Future versions will also allow C++ plugins. It's still very incomplete, but it looks promising.

Of course it's nice that you can now throw together a working Symbian app in a very short time, but it's kind of sad that you could probably construct an app with the same functionality in C or C++ almost as quickly on a platform with decent API:s. It's always nice to have different alternatives though, and the number of options are increasing quite a bit these days, with SymRAD and the recently released PIPS and Open C packages. None of these is a complete solution, but anything that can improve the situation over what's been available so far, the Symbian C++ framework, Java and Python, is good news.

This is not a CV

I just thought I'd introduce myself, to show where I come from and how I ended up in the world of mobile phone development.

My first job was at a small company called Aurora Innovation in Uppsala, Sweden. It was actually a spin-off from mine and Robert's thesis project, which had nothing to do with mobile phones, but with feet and shoes. We built 3d scanners from old record players and webcams, until the shoe project was dropped and we moved into cellphones, more specifically Series 60 smartphones. This was back in 2002, so the available models were the 7650 and the 3650. We developed a system that was really a glorified answering machine, and we worked on it until I started to feel too much like Dilbert and quit the job, after about 9 months of Symbian development. I gained a lot of experience with closed API:s, lack of documentation, and co-workers getting so fed up with the latter that they started throwing things.

Fast forward to 2005 and I got a job at Synergenix, the mobile games publisher, where I maintained the Symbian port of the mophun gaming middleware for about a year. I had a great time there and learned quite a bit about mobile gaming, ARM assembly, active objects and platform security. My main achievement there was porting mophun to S60 3.0, which taught me a lot of about platform security and the sorts of obscure bugs you'll run into when porting to a new ABI.

In September 2006 I left Synergenix, which had then changed names to Blaze (and was soon thereafter bought by Oberon), for a new job at TAT. I can't tell you much about the projects I've been working on there, but my previous Symbian experience has proven very useful. And it's a joy not to have to work as a 3rd party developer anymore, with all the lack of documentation and support that that brings on.