Tuesday, March 27, 2007
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).
Monday, March 26, 2007
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.
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.
Friday, March 23, 2007
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.
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.
Tuesday, March 20, 2007
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.
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.
Friday, March 16, 2007
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 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.
Tuesday, March 13, 2007
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.)
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.)
Thursday, March 8, 2007
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...)
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.
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.
Wednesday, March 7, 2007
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:
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.
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.
Tuesday, March 6, 2007
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...
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...
Saturday, March 3, 2007
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.
Thursday, March 1, 2007
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.
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.
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.
Subscribe to:
Posts (Atom)