Smartphone OS market share in 2007

I'm a big fan of Simon Judge's blog, Mobile Phone Development, and I read his article about Q3/2007 Smartphone Market Share with great interest. I agree with his findings, however, I would add my own thoughts to it, too.

I found it very interesting that most people might not noticed without paying careful attention to the details, that there are already more smartphones running Linux than Windows. It was surprising for me to see that as I've sort of had the impression so far that even though mobile Linux has its potentials, it still hasn't gained much market share as of yet. Well, I was wrong.

The next thing worth noting with regards to mobile Linux that almost a quarter of the whole report is about explaining why mobile Linux would be a bad alternative for manufacturers, operators, etc. Surprisingly, considering costs as well. That, of course, shows what Symbian really thinks about this threat.

As to Windows Mobile: I've also read a couple of reports, where analysts predicted that Microsoft would take over the lead role as mobile OS vendor from Symbian by 2010, but I also believe that it's unrealistic. Although I recall a question I was asked informally by someone in London, where I attended Forum Nokia Developer Day this October, that what I was thinking about the competition between Microsoft and Symbian. I asked back: is there any competition? This might sound as a joke and now I think that I was too self-confident: although Microsoft might not pose a big risk to Symbian as of yet, it's still a key player that's just getting stronger over time.

I've just read it at over IntoMobile that iPhone outsells e.g. Nokia N95 in Europe. Well, although it's a BIG warning sign, let's not forget about that Nokia

• has a bit more phone models than Apple (ehm, 1?)
• is going to introduce new phones with touch ui support (also with tactile feedback!) in 2008
• also very importantly is working very hard on providing internet services (Ovi, MOSH, Music Store) to increase customer loyalty. Similarly to Apple, by the way.

Finally, some notes on mobile OS market share in the US:

• There are two vendors who have much bigger share here, than all around the world: Microsoft and Palm. Their cases are pretty much different, though: whilst Palm will potentially disappear from the (rest of the) market in the not-too-far future, Windows Mobile is predicted to gain bigger share from year to year.
• However, it's not only these two players among whom the market is split. Or at least will be soon. Apple has just jumped in to this business with great initial success. Although selling pretty well in Q3/07 is something remarkable, they still need some time and stable growth to catch up.
• Symbian fills a marginal role in this part of the world, but as we all know Nokia and Sony Ericsson are both working hard to change the situation. Nokia has, for example, just teamed up with Verizon (ehm, it was Verizon who joined Nokia, actually) for developing a fourth generation mobile broadband network. I believe a successful co-operation with a big American carrier is the first step for Nokia to gain a foothold in US. Sony Ericsson, on the other hand, has sold 50% of their share in UIQ (a company, but also the name of a Symbian variant) to Motorola. Even though Motorola is said to be fighting for survival, they're still a key player whose help might always come in handy.
• Finally, what is not in the figures is OHA: although they're still nothing more than a promising alternative now, the first phones based on Android will appear during next year - I wonder if they will be able to make as a good start as Apple did.

Your thoughts are welcome - as always!

Tote

Tilt-O-Mania, also known as Nokmote

Have you ever felt that your idea is stolen and "Damn, I wish I had been faster in doing it"? Now I feel exactly that way.

The first time I heard that another Nokia phone, N95, has a built-in accelerometer I started wondering why on Earth? Why on Earth is it worth for Nokia to put such a device in their phone? Has Nokia 5500 Sport (first Nokia device with built-in accelerometer) proven that it's worth making further experiments with? I haven't seen any analysis telling so, although I admit that it doesn't mean anything. Why on Earth has Nokia kept it secret that there was such a gadget in their hottest device? Is it a secret? Isn't it something that makes the device even cooler?

Then I started to think about what we could do with it? First, I thought RotateMe was a great software, I really liked the idea. But I felt something was missing. Then I found it: why not simulate joystick key presses (i.e. left, right, up, down + press) by tilting the device to the right direction? Since it's fairly easy to simulate key events in Symbian C++ just as if they had really occured, I thought it was easy to implement. The good thing in this idea that it works with existing software, no need to re-write or adapt anything: applications will not notice the difference between real keystroke and simulated.

Tilt-O-Mania

That would have been the name of my software. R.I.P. Now it's called Nokmote and it's not mine at all. :( Sorry guys behind the "sad smiley", I'm happy that you'll come out with an implementation, but I must tell you that I'm unhappy that you'll come out with it. :)

To be honest, I was always wondering why nobody had ever discovered the opportunity in writing such a software. As more and more S60 devices will come out with built-in accelerometer this feature could become such an integral part of user experience that even Nokia might want to use it. I dare to claim that even the joystick could be replaced by the accelerometer + this solution in the future. Not only could Nokia save some money by removing some existing hardware (i.e. the joystick), but they might even be able to use the new spare space for other purposes. Isn't it so cool?

And you know what? The solution is not Nokia/Symbian specific: any (mobile) device having a motion sensor could do on-screen navigation like this. Another Symbian phone, iPhone, gPhone even a laptop, though it would be funny to see a businessman tilting his computer at the airport just for the sake of navigation. :)

On the other hand, I was shocked to find that my(?) idea was not original at all. I mean not that now somebody has come out with an implementation for S60, but this idea was implemented years(!) ago on another mobile phone. You know, some of my colleagues have worked with a MyOrigo device and when I told them my idea they enlightened me that it had already been implemented. Check out this article from The Register and you'll see that such a device is already on the market. Okay, it is a not-really-famous mobile phone and perhaps it doesn't even make use of accelerometer data, but still the idea is theirs: user tilts software navigates.

Never mind, although I'm sorry to see that I can't be THE pioneer in this area, I'm happy to see that it'll be available to us soon. Good luck for writing the software!

Tote

Android SDK is out - first impressions

After watching the video about the introduction of Android for developers, I'm convinced that the new phone will generally be as useful and user-friendly as e.g. the-also-newcomer iPhone. Well, it came as no surprise to me, I'm just expecting a lot of innovation from the new player in mobile space. I don't expect that the new platform will offer as many features as traditional Symbian-powered devices and I can even dare to say that it's not going to be as stable, either ... yet. However, I'm pretty sure that they will catch up soon and offer real alternatives for users, phone manufacturers, operators, etc.

What has totally escaped my attention, though, was that the programming language for this platform would be Java. Based on the fact that it's going to be a Linux-based OS I kind of anticipated that the programming language would be C/C++. I don't know the rationale behind this decision, but it will definitely give a boost to the otherwise stagnating JME programming environment.

I wonder, though, how Google is planning to solve the infamous Java fragmantation problem for mobile phones. What is that? Well, even though Java is a very popular and platform-independent (aka portable) programming language, it's just the set of Java core services that is available on every mobile device. The presence of additional features, such as advanced mobile graphics, security, etc. depend on phone manufacturers' decision, whether it's worth adding them. Which makes Java mobile applications market very fragmanted (some features are available, some are not) and development very frustrating. You know, I have heard an example that a mobile Java game programmer had to make 100(!) variants of his game "just" to be able to distribute it to as many phones as possible.

Another thing about mobile Java development is that most mobile phones are running on another operating system than Java. In fact, Java is not an operating system at all, even though there have been attempts to make Java-based mobile platforms, see e.g. SaveJe for more details. But Symbian OS is similar to Android platform in that they both have their native platform (Symbian OS and Linux, respectively) meaning that platform features are usually available in native programming language first and then some JNI layer added on the top and there you are, it's ready for Java programmers. So far so good. However, it introduces some latency in the equation as it requires some time to write features in native environment first and wrap it in the second round. Will Android suffer from the same problem?

My regular readers already know that I was involved in S60 Browser development and it was very challenging and I really liked it. For that reason, I'm happy to see that Google chose WebKit for their mobile browser (S60 Browser is also based on this rendering engine) and in the demonstration it worked well. I was wondering which display method they would choose for web pages:

• S60 approach that displays the web page in its entirety without scaling
  
• or iPhone approach that scales down the web page to so that it fits to display dimensions, though it's hardly readable, but lets the user zoom it very conveniently (e.g. by double-tapping on screen)

They actually chose both: they first display the page without scaling and then user can scale it down for better navigation. I'm pretty sure that Nokia has their own IPR on MiniMap (i.e. the zooming interface) so that might be one of the reasons why Google didn't choose that option. However, what surprised me that they use the same visual history for page navigation as in S60 Browser.

So these are my first impressions after spending half an hour with Android after midnight. I'm really keen to hear your comments - just as usual! :)

Tote

[Update]: I'm shocked, check this out: Dalvik: how Google routed around Sun's IP-based licensing restrictions on Java ME. It basically says that Android phones will NOT be JME-powered, but you can write JSE programs to them. With Android, Google has introduced their own VM, Dalvik, which eventually does not make use of Java bytecode, but their own Dalvik format. It's all to get rid of Sun being involved in licensing.
It's another question how good or bad will it be to the community. It means a new variant on the horizon, a VM incapable of running so-far-standard Java bytecode, thus your midlets will have to be re-compiled. I can see why Google is happy to have their own solution to this problem, but I can also see why developers would be unhappy due to that they'll have to take just another Java variant into consideration. Even if their pockets will be full with (Google's) money.

Join Forum Nokia LaunchPad - 25% discount

Nokia is famous and well-known of their developer support. Forum Nokia is a portal for anybody interested in tools, documents, techniques and insights to developing solutions running on Nokia devices. The recently renewed site now contains a very popular community-driven forum, Wiki, blog, etc. for everybody's use. All this for free.

However, sometimes even this extensive support proves to be not enough. There are cases when you need more information from a more reliable source in shorter time. In other words, more support. And this is when professional support comes into play. Something that you don't get for free, something you have to pay for.

What is this professional support and what do you get for your money?

Whilst there are many kinds of professional support provided by Nokia, I'd like to talk about two of them: Forum Nokia PRO and Forum Nokia LaunchPad. I'm pretty sure that you have already heard of Forum Nokia PRO, available for professionals for years by now. The benefits of this program is well-described here, it's worth noting that it is invitation only. As opposed to Forum Nokia LaunchPad, which is available for everybody, individuals and companies alike. Benefits include free copy of Carbide tool, discounted tech support, application signing, books, early access to technical information and lots more. Although there is a clear difference between services provided for PRO and LaunchPad members (former naturally gets more), I believe it's worth joining either program if you're a serious developer/company.

And here comes the deal

As a Forum Nokia Blogger and "self-appointed LaunchPad ambassador" I am entitled to offer you €200 off the price of Forum Nokia LaunchPad's (otherwise) €800 membership fee. Yes, that is 25% discount! If you have been thinking about getting more from Nokia and joining LaunchPad program, this is the right time to do it!

How does it work?

I give you a promotion code, namely LP600 (short for LaunchPad for €600), that you can use when applying for Forum Nokia LaunchPad membership and that's it! You just need to enter the above code (in Promotional code field) right before pressing Submit and you're done, you pay less.

Convinced or eager to know more? Just visit Forum Nokia LaunchPad for more information and apply for membership!

Tote

Symbian Platform Security - hacked?

Well, 3:00am has already passed and I'm tired and sleepy. One thing doesn't let me sleep, though. I've just stumbled upon these articles (Exploring S60 with AllFiles and Goodbye S60 Platform Security, Hello CAPABILITIES!) and I can't believe my eyes: Platform Security hacked?!

Briefly, the solution is as follows:

• Take a firmware update package (currently supported only by Nokia for their S60 phones).
• Edit a well-isolated part of it, where all those capabilities (i.e. rights) are listed that a user can grant to a 3^rd party application upon installation. Remove existing capabilities, add new ones, whatever.
  
• Flash it.

Now you have such a phone (software) that allows you to give so powerful rights to any 3^rd party application that they can do basically anything on the device. For example, your program can access DRM-protected content (you've downloaded it once and share it with others), browse other applications' secret folders, etc. You just need to

• Extract a signed SIS (Symbian Installation) file
• Add rights to it (whatever gives them more power)
  
• Re-pack & sign it again
• And install it
• Although the Software Installer will notice that the application was not properly signed (== acquires for more capabilities than it can normally have), the user will be in such a position that he can grant those extra rights.
  

Actually, this is the approach that the author of the aforementioned articles followed with regards to a very popular file browser application: he added AllFiles capability to the program so that he could explore the entire file system, which he hadn't been able to do until then.

Unfortunately, I can't prove or disprove whether this solution really works, since I haven't even updated my N95's firmware yet (shame on me!). However, this guy seems to know what he was talking about and I sort of a believe him.

In any case, if what he wrote happens to be true, then I have a few questions:

• Why on earth did Symbian publish such a confidential information that is useful solely for phone manufacturers? You know, the documentation of Software Installation Policy is a very internal thing, not anyone's business. You can see that it's enough if one talented person stumbles upon that documentation and uses it.
• Why is a firmware package in such a format that anyone can edit it? I mean, locally on their machine. Okay, with such a low-level tool that very few people are familiar with, but it's still possible. Wouldn't it have made more sense to encrypt and sign the package so that
• it cannot be decrypted by 3^rd parties (well, easily at least)
• it gets decrypted only on the target device right before flashing?

You know, I'm not a security expert, so I might easily be suggesting a stupid thing, but if there's any chance to do it that way, I think it's definitely worth the effort.

• But even if it's not viable, then why does the firmware package update the whole system including the most critical parts? You could see that one can change the software installation policy this way. Why not make a process consisting of two steps:
• User can download and flash a firmware package that updates the (vast) majority of the system, but it doesn't allow him to touch the critical parts
• Those critical parts can either NOT be updated at all or only at service points.
  

I just really don't know what I've expected from Platform Security, but I have a feeling that in my secret dreams I thought it was unbreakable (I know, I'm naive). Again, I'm still looking for confirmation as to whether this solution really works, but I'm afraid that I already feel the bitter taste in my mouth. You know, a system that Symbian is proud of, operators love (some developers hate:) and even competitors acknowledge shall not be attackable and even if a security hole is discovered it shall be closed quickly without any major impacts. Nevertheless, I think this problem can be solved - hopefully very easily. But as to injecting the fixed version on to old phones, it will just take another firmware update. :)

Tote

Update: another fellow Forum Nokia Champion of mine, Antony Pranata, wrote an article about the very same topic. I think it completes my post in addition to confirming that the solution works. Worth reading.

Symbian development - An alternative to embedding applications

I usually don't write articles about actual Symbian development issues, but this time I think I make an exception, if you don't mind. If you don't speak "Symbianish" or simply are not interested, then please skip the rest of my post. Nevertheless, I hope that the majority of you will just keep on.

I was in London on last Sunday for Nokia Developer Day. I was invited, because I'm a Forum Nokia Champion. There was an interesting presentation about Location Based Services and some technical details were revealed as to what Nokia would come out with as part of their upcoming SDK, namely S60 3rd Edition Feature Pack 2. It's not secret that they're going publish Map and Navigation API and an important feature of that API is the ability of launching Maps application stand-alone or embedded.

If you speak Symbianish, then you should know what launching an application in embedded mode means: your application loses focus and hands it over to the embedded application so that you have no control over it as long as that application owns the focus. It's worth noting, though, that albeit your application has lost focus it's still the main (hosting in other words) application that just makes use of services provided by another application. This can be seen by having a look at the list of currently running applications, where it's the name of your application that is in the list and not the one you have embedded.

The advantage of launching an application embedded in your application is that you don't have to bother with how it works internally, you just start it up and basically rely on that it works properly. On the other hand, this way of using other applications' services has disadvantages, too: one is that you have no influence on the menu structure of the embedded application.

Why is that important? Well, a real use case that we had to implement recently is that an application 1: shall be able to show some points-of-interest (POIs) on a map and 2:
shall have its own menu structure. We were happy to hear that Map and Navigation API would be available for public use, however, launching Maps application to satisfy our first requirement would mean that we would not be able to satisfy the second.

Then I started wondering how it could be done. Since I was deeply involved in the development of S60 Browser application some time ago, I know quite a lot about the application and the ecosystem around it. For example, I knew that a new approach had been introduced as part of the "Browser-offering" ~2 years ago that allows an application developer to use a (CCoeControl-based) control in her application. That control is called Browser Control (its API is BrowserControl API) and basically it is capable of showing & handling a web page just as the built-in Browser application does. So essentially your application can have its own menu structure, whilst also being able to show a web page. It gives you more flexibility and freedom if you use this API in favor of launching Browser in embedded mode, however, it's also more complex - sometimes unnecessarily.

Finally, we reached the point of my article: wouldn't it make more sense for applications that can be embedded (since not each application can be embedded) to offer such a (CCoe)control-based solution as well? For example, if the newly announced Maps and Navigation framework published such a service, then I shouldn't be worried about how to solve my problem. But this question is more general than to narrow it down to this special use case. I think, if some architects and/or lead designers from Nokia read my article, then I suggest them to think about it.

As a last thought, you might be wondering how I'm gonna work out this problem eventually. Well, there happened to be another presentation on that very day (i.e. Sunday) about Web Widget development on S60. I'm just thinking about writing an S60 widget that makes use of Google Maps API so that everyone is happy. :)

Any comments are welcome!

Tote

Treading on shaky ground

If I were Dumbledore, then I could put my thoughts, memories in my pensive to keep my mind clear and fresh. But I'm not him at all and my mind now feels overburdened with news that I can't keep in - so I let them out.

You know, it's a great thing to tag blog articles. It keeps them categorized, easy to look for, easy to oversee, etc. What I'm now about to write, though, fits in a new category (well, at least to me): treading on shaky ground. What is it? You'll see, just read on!

Everybody paid immediate attention to one of Nokia's recent acquisitions, the agreement for Nokia to acquire NAVTEQ. You know, two things couldn't escape most people's attention: first, the huge amount of money Nokia is willing to pay ($8.1 billion!), second, that it is such an area (GPS and location-based services) that hasn't been fully explored yet. They must foresee something (and of course play an active role in it) that others haven't been thinking of yet!

And it's not the only acquisition Nokia was recently involved in: for example, they also merged with Enpocket. This deal is to give a boost to advertisement after the public announcement that Nokia is opening to the Internet. Not as if we didn't know that NSeries is open to anything, we now know that to the Internet, too. In addition, and I'm sure most of you already know, Nokia has launched new services for content download & consumption lately, check out Ovi and MOSH to see what I mean.

So good, so nice. But you know what? There are some parties who are not happy with Nokia opening to Internet and offering content online. It's said to be the operators (carriers in US) who will lose the most money if Nokia happens to be successful in this area. Although their online offering (mostly ringtones and themes) can usually be described with one word, pathetic, they're still the biggest revenue generator for Nokia. What happens, for example, if some UK operators refuse to sell new Nokia models? What happens if others follow them? Although, as I've already pointed out, Nokia might not be really affected by such a sudden(?) move in the US, it'd still be an unpleasant thing to happen to Nokia. I sort of have a feeling that what we see happening around is a total war between Nokia and others (operators, mobile manufacturers, OS vendors, etc.). That's the way how it goes.

As to mobile operating systems, the competition is also getting more and more tough. Although it's nicely put by Atmasphere that iPhone is a feature phone, in contrast with N95, the über-smartphone, Apple definitely has influence on newer phones not only from Nokia, but other handset makers, too. It's also worth noting what he found about the afore-mentioned two phones:

The iPhone is for consuming content, while the N95 is for creating it.

So from that point of view, Apple might not pose a considerable risk to Nokia's position yet. But how about Google? Even though it's a bit of an old news that Google is working on a mobile OS, I'm wondering how it will threaten Symbian's future. It's said to be a Linux variant (a new distribution to make the market even more fragmented?) and of course will be ad-supported (== cheap). Looking forward to it!

Thanks for being my pensive so far, I feel really relaxed now. And also eager to know what you think about all these things I've mentioned!

Cheers,

Tote

Being featured by Nokia

I am honoured to be the featured Forum Nokia Champion this month. However, to be honest I was not prepared for the increased interest about me and my work and surprised to see the flood of e-mails day by day asking me for help regarding this and that problem. I try to answer these e-mails as thoroughly as I can, however, I'm afraid I can't give perfect answers to all of them.

Nevertheless, e-mails are only one thing. People are asking me to let them join my LinkedIn network, too. Although the way they're asking it varies case by case, I'm afraid I have to refuse these requests all. You know, my biggest concern is that I wouldn't like to acknowledge that I know someone with whom I've never met. And since giving referral of someone is one of the core features of this networking site, it simply doesn't make any sense for me to do so.

But the last thing that happened to me just the other day is that I got an e-mail from Sargam Bansal. Yes, right from him (her?). I don't know where he took my e-mail address from or if it has anything to do with me being featured by Nokia, but it doesn't matter at all: he found me. Let me cite his e-mail in its entirety:

to: my e-mail address
cc: Olli-Pekka.Kallasvuo@nokia.com

Dear Sir,

I ve been using Nokia for past 5-6 years.
I had submitted my Phone NOKIA 3250 at Nokia Care Centre Sector 3 Noida(JOB SHEET NO:-1200196776 ; Serial No :- 357933005291399) for the problem it used to hang when music was on & some call used to come.

I got my cell after 15 days & after that the phone's condition was horrible. Itwas completely damaged , not even it was able to switch on. The Phone was submitted again. It been over one month & on each visit they are delaying the date.Not only me many people coming there are totally frustrated for the service being provided by Nokia care centres .

I emailed over a week ago and I have not received any reply. Similarly, when people email Nokia's Customer Support they are getting no response, which is surely unacceptable.
Due to such irresponsible behaviour, there has grown immense dissatisfaction among us, the users of NOKIA & also it makes me doubted about the name NOKIA have had in the past years. Now it has became a difficult question to answer.. Can we really trust NOKIA now???

I am sure you will be concerned about this matter and I would respectfully ask for your assistance in arranging for Customers to better informed and to receive prompt responses to complaints and enquiries.I hope you can agree that this should not be too much to ask nor beyond the capability of Nokia.
Thank you. I look forward to hearing from you.

Thanks & regards,

Sargam Bansal

Regardless of the seriousness of this e-mail, it's quite obvious that I can't help. Other than publishing this e-mail so that other (more competent) people can also read it and possibly react on it. However, there is one thing that I hope you have also noticed: who was cc:-d in this e-mail? Olli-Pekka Kallasvuo, Nokia's CEO and not other. You know, I've never dreamt of being in the same e-mail group than him, but now that I have achieved it, I think I'll make an exception with Olli-Pekka: I'm ready to accept his invitation on LinkedIn. :-)

Tote

Time of competition - a peaceful summer?

Summer is hot, silent and peaceful in Hungary. I can just sit back and watch/read what's happening around the world. And in mobile space, of course.

Well, it's not that silent as I expected. In the past few days I have noticed new signs of a tough competition between mobile- and consumer electronics device manufacturers, internet service providers, mobile operating systems. Let me go into the details!

Although Nokia is clearly a market leader, they have to listen carefully to users' demand. On smartphone market, for example, there's a new challenger who demands everyone's attention. There's been a lot of discussion over whether iPhone is a smartphone or not, but that's not my point now. They clearly showed people how easy to use a user interface (UI) can be (I also happen to know how an iPhone blends, but that's a different topic:). However, the UI is not everything: there must be great (and well-implemented) features in the phone, too. You know, just in order to make a phone smart - if that's Apple's intention at all. It's not obvious as the mass market (=biggest revenue) of mobile phones is NOT smartphones.

These times everyone is trying to imitate iPhone's behavior on their phone; even one of my friends has put a new "iPhone shell" on his Windows CE phone - just for the feeling's sake. :)
Other people, on the other hand, wonder if iPhone is really selling at the same pace how Apple claims to be. You know, it's just one thing, they say, how many phones Apple and AT&T could sell so far (not to mention how many have actually been activated), it's just the hype that keeps selling at this level. Sooner or later, however, everything (and everybody) will calm down and we'll see how successful Apple is. Let's see!

Another company is also trying to expand into this new area - at least new to them. It's been announced several days ago that Google invested in cellular technology. No surprise, we already knew they're interested in this technology area (i.e. mobile), too. What might be a sign of a new aggressive campaign is that Google makes the conditions to FCC for a wireless spectrum auction. You know, I pretty much sympathize with Google in this case and hope that not only will the rules change (free download of any applications, services or content), but the list of operators will be refreshed, too.

By the way, Russell Beattie is back. In case his name doesn't sound familiar to you, he's an American blogger (one of my favorites) from the Silicon Valley full of great ideas. This time he shared his opinion with us how he sees the future of Nokia S60 UI. He's not alone with the vision that Nokia will change to Linux from Symbian, what he adds, though, is that he expects (or rather suggests) Nokia to revolutionize their UI, too. Neither would be an easy change just a side-note.
On the Linux issue, it's been already told that royalty-free doesn't mean entirely free at all. There must be (lots of) people who customize Linux to the needs of manufacturers, operators, follow market demands, adds features to Linux that have never been implemented since Linux originally has not been a mobile OS. The interest of all the possible players is very fractioned, there're already several interest groups who are doing their own design, following their own desires, etc.
On the other hand, there're lots of things Symbian (Nokia, UIQ, etc.) could learn from Linux, especially from their developer community. For example, I'm not sure if you've heard about the service outage of Symbian Signed that happened recently. For example, one of my fellow Forum Nokia Champions, Antony Pranata, was in trouble due to this. There are other people, too, who are not too happy with the current situation and think Nokia and Symbian could make it better.
Finally, as to the UI revolution: I'm pretty sure that everybody at Nokia has already drawn the conclusion from iPhone's success. I bet they've even already started to design the new approach of a touch-based model from Nokia. I'm really looking forward to it. And finally, a side-note to Russell: not as if it was a trivial step for Nokia to get rid of their "old" UI design in a jiffy. The UI (believe it or not:) is one of the core features people love the most in their Nokia phone. They might interpret a radical change in the user interface in a way that would make Nokia, khmm, unhappy.

That's it for now, I'm looking forward to reading your thoughts!

Tote

Nokia's new strategy in US market

I, and other much wiser bloggers, have already written about how unsuccessful Nokia had been in selling phones on the US market. It seems that American people are resistant to smart phones, they're simply satisfied with text messaging and using their phones mainly for voice calls. Unfortunately, the carriers didn't make it easy for Nokia to be the #1 in North-America, either.

But that might change over time. As Nokia reported in their press release, they are trying to find new ways to sell their phones, but this time without involving the carriers. I hope that Ewan's prediction will come true and users are now ready to buy and use such advanced mobile gadgets. Especially if they are from the business segment: first, it's more likely that those users can afford cell phones for hundreds of $s, second, they might even use more than 10% of the provided functionality. :-\

Let's see, I really wish all the best to Nokia! You know, my future might depend on it. :)

Tote

Forum Nokia Champion Day in Singapore

Hmm, I've already wanted to write a blog about this event, but it seems Naresh was faster. :) Anyway, I can add my thoughts, too.

So, one of the great benefits of being a Forum Nokia Champion (or FNC) is that we can attend the FNC Day held twice a year at various locations. The first was in San Francisco, which I unfortunately couldn't attend. The second was held in London just one day before Smartphone Show, 2006. That was great! First, I always like kind of networking with other people who are interested in the same area (i.e. mobility). Second, Nokia is a gallant company meaning that we couldn't have any complaints as to how we were treated during these events.

For example, let's take this event that took place in Singapore. Not only did Nokia pay for the accommodation in a 4-star hotel, but - for some of us - they also paid the airfare. Okay, we've got it as a reward for contributing to the successful launch of Forum Nokia Wiki, but still: let's say it was a fair deal. :)

By the way, I thought in the beginning that Singapore was not the best selection for the FNC Day. Not as if it wasn't a nice location, but it's too far away from most of us. But still, about 20 of us could make it and were there and it was fun to be there. I liked all the Indian guys (they were the nicest, the funniest:) and it was a pleasure for me to meet "TCB" Paul (I could never imagine that a 3rd-party software could get TCB capability), "FlashLite Master" Alessandro, "Medical Man" Arto, "Y-Browser" Jukka, Paul "My students can do everything" Coulton and "I evangelize Python for S60" Jurgen. It's by far not an exhaustive list of people who were there and I enjoyed staying with - I've just picked up some from my memories.

So, I'm pretty much satisfied and happy that I could be there, now I just need a few days (weeks?:) to relax and recover from the long flight. :) Thanks Anina, Hung and the whole FN Champion team to make it happen! I'm wondering, however, where the next event will be held. London, New York, Brazil? Why not?

Cheers,

Tote

Symbian Signed is not an anti-virus software

The Register reported today that a new spyware for mobile phones had appeared on the horizon. It's harmful for S60 phones, too, 3^rd Edition devices included. And what causes the stir in the water is that it's a Symbian Signed application.

There's a general misconception here, I'm afraid. I think the biggest problem most people don't understand that signing has not much to do with protection against malicious programs. These people don't understand that the process is about signing (surprisingly), i.e. certifying that the application comes from a well-known source. Additionally, in order for an application to be Symbian Signed it must undergo thorough testing being done by independent test houses. Since this application is Symbian Signed, it must have passed those tests.

The problem is that it's impossible to test everything an application can do. It's even possible to acquire for a capability (and get it!) just by saying that the application needs it for a different purpose. As this example shows: I can ask for e.g. NetworkServices capability and say that I need it for remote backup. And then make no mention on the fact that I will use it for other reasons, too. You know, it can be done since no-one checks the source code, it's not part of the approval process for Symbian Signed certification. And it will never be, I suppose, as no-one will ever share their best kept secret (i.e. the source code) with outsiders.

What Symbian (Signed) could do better, though, is that they shouldn't advertise these signed applications as "trusted". Because they aren't. What you can trust, though, is that the author of a Symbian Signed application is accountable. If he/she/they produce a software that proves to contain some malicious code, then they can be "caught" and counter-measures can be taken. What counter-measures? For example, the author's certificate can be revoked and added to a list, called Certificate Revocation List or CRL for short. This list can be always checked upon on-line. For example, when a user is just about to install a 3^rd party software whose author is not known (or at least not trusted), the Application Installer can do this cross-verification as part of the installation process. Pretty useful info, isn't it? Worth noting that most users are not aware of this and they have this feature disabled on their phones. Including me, but that's on purpose. :-\

Just my two cents,

Tote

My new N95 - comments

I have received my new Nokia N95 device as a reward from Nokia for contributing to the launch of their new service, Forum Nokia Wiki. I was among the top 10 Forum Nokia Champion contributors, you know. We have received something else, too, but it's still too early to talk about it. I'm planning to get back about it in a month or so.

Well, I was very excited about this device, because I must admit it was my dream device. THE smartphone that I've always dreamed of. I have read couple of reviews on it by now (e.g. on AllAboutSymbian or Symbian Freak) and I was very convinced that the only issue that these reviews had found in common was the battery. The fact that it gets exhausted very easily, very fast. That's okay, I thought, I believe that's an issue that I can easily handle. I'm sure that Nokia is aware of this problem, too, and they're on it to fix it. Not necessarily with this phone, but with future phones.

However, I think I can tell you/them a few other hints they might want to pay attention to. Or maybe not, but at least I did not keep my comments secret on this great device. :-)

• Lack of memory card in the package. This is the third device from the N-series that I have got without any multimedia cards. First, an N90, second an N73, now it's an N95. Hey, it's a multimedia phone and I can hardly believe that the built-in storage is sufficient for multimedia purposes. And I can't believe it, either, that Nokia is to save some money on NOT including a memory card in their sales package, because the price of such a piece of hardware is so low. Then why is it not included?
• Battery. The topic that I have already mentioned. It's just right my second day, but it has already proved to be true that I need to charge the battery once a day. I was already recommended to get used to it, now I'm on that path. :-|
• GPS. This is the first GPS device of mine, so I don't know too much what to expect from it. I can see, though, that the built-in program is data-hungry and tries to get that data from the internet (without a network connection it doesn't really work, i.e. is not really useful). It's not a good sign for me, because I have decided not to spend too much money on using GPS, but try to keep my spending as low as possible. Perhaps the installation of additional maps will solve the problem, I don't know, I'm just hoping that.
• Connected to TV. There is an RCA jack included in the package with which we can attach the phone to the television so that you can see it real-time on your telly what you're doing on your phone. It's a pretty nice feature that can be used, among others, for demoing, showing your pictures/video/etc. to your family, browse the web in full screen on your tv, etc. However, for some reason, voice was not audible when I was e.g. playing a game. I'm unsure as to where the problem is - on my phone or with my TV, in any case, it's waiting to be fixed. Just tell me if you have experienced this and managed to get over with it.
• Localisation. You know, I'm from Hungary, Europe and although I'm pretty much happy with using English I've already got used to using T9 on my phone. It's such a brilliant feature that now I can hardly live without (at least in terms of short messaging:). The problem is that as I have forgotten to indicate my wish to have Hungarian language included on my phone I can't make use of (Hungarian) T9, either. Unless somebody smarter than me enlightens me how to fix this problem with the least pain.
  

That's it for now! By the way, before I forget: thanks, Ron and Forum Nokia, for this great device. It was really worth the effort of contributing to the Wiki. I wonder if others know that they can win an N95, too. :)

Cheers,

Tote

Design patterns in Symbian

This time my post will be a short one. :)

You know, I've been thinking about writing some posts on various design patterns applied in Symbian OS core components. My motivation is first that I enjoy reading/using code that has been carefully and nicely designed. Second, I wanted (and I still do) to encourage each developer to always think before starting to implement any solution for a given task/problem. It may sound as a cliche, but I found it a very common pattern that people (i.e. developers) had not considered how others will use their module (niceness of interface, readability of source code, etc.), how it fits into the big picture, how future-proof it is, etc. You know, ideally you shouldn't just code something, but rather do it nicely. That's the difficult part.

Even though I found this idea pretty challenging I've kept postponing my first article on this topic for various reasons. Now I'm late - at least with the first article. :) I've just noticed that rensijie from NewLC.com had posted two article about design patterns:

• When Symbian met Design Patterns (1) -- State Pattern and
• When Symbian met Design Patterns (2) -- Proxy Pattern

Good posts, Rensijie! I'm really looking forward to the next article on the topic. Or even I might add some. :)

Tote

Forum Nokia Wiki - the responsibility of contributors

As Ron from Forum Nokia announced, Forum Nokia Wiki has been launched just a week ago. We, Forum Nokia Champions, were asked to fill the Wiki with contents a few weeks earlier so it wasn't news to us when it was launched. Nevertheless, I thought it was a good thing to have a centralized knowledge base online available to anyone wishing to find answers to their technical questions. Ideally it's going to be updated regularly with high- and low-level information alike (e.g. architectural vs API-level) sharing all the knowledge that lots of developers have gained on many areas that have anything to do with mobile development. I believe it was a good step waiting for being made by Nokia.

However, users of a wiki system must be aware of that there are some rules that every contributor should follow. Because one side of the coin says that a wiki can be edited by anyone, the other side, though, suggests that it ought to be done well. For example,

• Most people know that copyrighted stuff shall not be added to the wiki, unless the author of the material in question has approved of doing so.
• Then it also has to be considered if the article to be added is really useful or not. Typically, "how to"s greatly improve the usefulness of a wiki, because what they explain is usually not mentioned in any off-line documents. As opposed to detailed API-documentation that should rather not be added to wikis (imho), since most developers interested in APIs already have a comprehensive API reference off-line.
• We have to be catious on adding new things so that they're in a readable format meaning that it can be digested easily. For example, I have seen articles that not only lacked formatting (I mean, at all), but they used internet-slang, like 'r u nuts?' (emphasis on one-letter words). I'm pretty sure that it's obvious to everyone why this style should be avioded in wikis.
• Finally, a very-very important thing: since anyone can edit any other people's article in a wiki, special care must be taken to change other people's contribution elegantly. For example, my articles have already been:
• Re-categorized - by removing a category which the article belonged to on purpose
• Re-formatted - so that external references (i.e. links) have been removed
• Truncated - some parts have been removed that should have stayed intact.

Unfortunately, all these changes happened so that no-one asked me what I thought about the changes and whether I approve them. Side-note: I would not have approved these changes, btw. Also note that above is not a comprehensive list of what people should keep in mind, I just picked up some topics.

You know, there're a lot of people who don't know that wikis provide means to ease what I call elegant contributions. For example, MediaWiki, a web based wiki software used by e.g. Forum Nokia Wiki or WikiPedia, provides watchlist, feeds, notification mechanism for regular contributors to make it easy for them to follow-up the changes they made. Each article can be watched so that any changes are visible when one is checking to see if an article has been further improved since the last check. Feeds enable you to check it out what the recent changes were, for example. Although automatically not enabled, but e-mail notifications can also be requested upon any changes to any articles.
MediaWiki also lets you initiate a discussion over a topic of an article so that people can come to a conclusion over a debated topic without changing the content of the article in question. This is the reason why there is a comment page attached to each article in MediaWiki. If those people who changed my articles had been aware of this feature (or if they'd cared), then their contributions wouldn't have left mixed feeling behind.

Of course, it's not only bad things that happened to the articles that I published on Forum Nokia Wiki, but the vast majority is useful additions and corrections. In addition, I'm so much amazed of the growth speed of the wiki and hope that it will be at least close to this in the future, too. But I also see that there're still lots of things to improve - Nokia Ron and his team and the future board of administrators will probably spend lots of hours with figuring out how FNWiki suits their users' needs in the most convenient way.

Keep up the good work, guys!

Tote

Protecting APIs - a different approach

I have been wondering lately if the current is the most optimal way of protecting APIs in the S60 (or Symbian in general) C++ SDKs. It must not come as a surprise to any programmers that there are far more features in these SDKs than what we can use with the publicly available functions. But they are usually hidden.

How? Before answering this question, some technical details. In order to use a certain feature in C++ the following two conditions must be met:

• The header file including the function to be called must be publicly available in the SDK,
• The component, typically a DLL and its associated LIB file, must be publicly available in the SDK.

The first condition ensures that the code compiles, the second that the link process will succeed. The most common practice that Nokia applies when they want to protect an API (i.e. not let 3rd party use it) is that they remove the header file in question. I would call it as a lazy protection as it does not protect against reverse engineering. For example, as soon as the API becomes publicly available there is nothing that can prevent a developer from making use of that functionality. Okay, Nokia clearly forbids reverse engineering in their license agreement, but there might be people who think it in a different way.

The second type of protection, let's call it hard protection, is to remove both the header and the LIB (that we import in our MMP) from the SDK so that neither compilation nor linking succeeds. Naturally, the DLL must remain in the SDK as usually it already has clients that use the provided functionality. This workaround is also applied by Nokia and Symbian alike. Sometimes they make it so that the LIB file is missing only under emulator platform (i.e. WINSCW), but not from the target platform (e.g. ARMv5). This makes it more difficult for developers to test their software - but not impossible. Since if you cannot link against a DLL statically, then you can still do it dynamically. You just need to use RLibrary class for that purpose and call the exported methods based on their ordinals. Okay, it's by far not trivial and now we're knee-deep in sensitive and confidential data, but it IS possible.

Let's just stop here for a minute to think about why Nokia (probably) follows the above-described practice! If I wanted to protect some data and not let others use it, then I would do everything in order to impede people to make use of it. Not just invent some hackish solutions that can be relatively easily bypassed, but make it really hard for others to hack. But it might not be in Nokia's interest to do so. You know, they have partners to whom they open up some - non-published, but available - APIs every now and then. And if they can choose from simply giving access to a header file OR sharing e.g. a LIB file, too, then they naturally vote for the first option. In my opinion it's much easier to do due to e.g. traceability reasons.

We have now finally reached the point where I can talk about my idea on a (probably) better way to protect APIs. You know, there's a rule of thumb in Symbian C++ programming as of the introduction of Platform Security: if you have sensitive information (I mean, data) to protect, then you're suggested to write a server and let it guard that data. This solution also enables you to smoothly control who and how can access the protected resource. I believe that Nokia has already re-factored their code according to this pattern so that all sensitive data is taken care of by various servers. These servers may then check against capabilities, secure and/or vendor IDs. Ideally, there is no sensitive data by now that is not protected by a server.

And this is the point where I ask: why not make every API public so that everyone can use it? Following from all above, security must not be a concern here, since access to sensitive data is already under control. On the other hand, developers could greatly benefit from having access to DLLs that have been hidden from them so far. You know, I'm talking about a big bunch of features that have been written by some talented developers at Nokia, Symbian, etc. and hidden unnecessarily. Why not let others make use of those features if it doesn't harm?

There's an exception, though. If the piece of information to be protected is not data, but an algorithm, for example. If it's not of big importance what data we work on, but how. Garnished possibly with some IPR issues. If this is an issue and the executing code is in a DLL (i.e. not behind a server), then we can't expect too much from Platform Security. We can assign some strong capability to the DLL so that using it would not be trivial for anyone, but we'd have no option for fine-tuned secure/vendor ID check, for example. Perhaps even capability constraints would not be sufficient, either. I think that we (err, I mean Nokia, Symbian and others) could re-use the existing approach in this case, that is, not publishing header and/or LIB files in the public SDKs. You know, I don't think we should fully get rid of the current solution, but at least suggest to use it moderately.

Wishing to read your comments!

Tote

Here is my program, sign it yourself!

I've bumped into the following blog today. This is exactly what I was thinking about a few weeks ago! I asked myself if developers could distribute their apps freely? Of course, the bottleneck is that they have to sign their apps properly, which is time-consuming and costly. But if one publishes his unsigned SIS file (it can be signed as well, since a file can be re-signed), then it can be freely signed by anybody else. So that the author can get rid of the burden of having to have his application SymbianSigned before distribution takes place.

One issue, though, that this workaround raises is trust. Why would I sign a SIS if it's from somebody whom I don't know? Why would I trust the program and presume that it will make no damage, generate extra cost, etc.? Of course, it's such an issue that must be carefully considered, case by case, program by program. But still there are programs whose authors are well-known and respected: they haven't all had time/money to bother with signing. Or let's take open source projects: unless they have good funding they will never spend money on content signing, which cost will never be returned. Not as if I was aware of such an open source project, but still. :)

So let's have a closer look at how it would work in practice! The classification of capabilities is as follows:
Group #1: User-grantable capabilities that can be granted by the user upon installation.
Capabilities: LocalServices, UserEnvironment, NetworkServices, Location, ReadUserData and WriteUserData.

Group #2: Powerful capabilities that cannot be granted by the user, but do not require any manufacturers' approval.
Capabilities: PowerMgmt, ReadDeviceData, WriteDeviceData, TrustedUI, ProtServ, SwEvent, SurroundingsDD.

Group #3: The most sensitive capabilities that only device manufacturers (i.e. not SymbianSigned or any other authority) can grant.
Capabilities: AllFiles, CommDD, DiskAdmin, MultimediaDD, NetworkControl, TCB, DRM.

If one writes a program that requires capabilities from groups #1-2 then it can be easily signed by anybody even if it demands some sort of technical mindedness. The steps for being able to install such a SIS file on our phone are as follows:

• Registration on SymbianSigned.com.
• Requesting a developer certificate for a given IMEI (i.e. the person's own mobile phone).
• Once having the DevCert, sign the program with it.

Following these steps enables anyone to sign any (Symbian) programs that can eventually be installed on a (Symbian) smartphone. On any programs, I meant those that do not require capabilities from the third group. Another constraint of a single DevCert is the inability to sign a program for more than one phone. That requires an ACS Publisher ID from VeriSign - costs 350 bucks, btw.

And what about those programs that use APIs protected by capabilities from group #3? For them, one must have an ACS Publisher ID even for a single phone. And not only is it the cost that might prevent most people from requesting a publisher ID from VeriSign. If you'd like to be able to sign programs with the most sensitive capabilities, then getting a publisher ID is the easier task. The second step is to issue a request to the device manufacturer in which you detail which capability you need and why. On API level (e.g. I need RFormat::Open() to use and for that I have to have DiskAdmin capability) and for each capability one by one. And believe me it's tough! It's time and energy consuming and sometimes doesn't lack unnecessary conversation with the manufacturer ('we don't think you need that capability' ... arghh).

As a brief summary I still think that it's worth going on this path. For a well-isolated target group, namely mobile geeks, but for them it's really worth. Yes, it's you who reads this blog. :)

Migrated from Forum Nokia Blogs.

Tote

Smartphone OS market share in 2006

An article on smartphone OS market share by region (between 2004 and 2006) made me think. Since I'm an analytical mind and also interested in this topic I've automatically started to compare the two figures. And as the author of the aforementioned article has left the analysis part to us (or was he just too lazy?:), I've taken the effort to draw some conclusions from the figures.



So, let's take the regions one by one as shown on the figures!
- European, Middle-East and Africa (EMEA): Symbian still rules smartphone OS market here.
- In Japan almost the whole market was ruled by Symbian in 2004. This has significantly changed by 2006 since Linux has appeared on the horizon with its ~40%! I bet Symbian is not too happy about it, even if they have shipped lots of new phones in Japan recently.
- China: first, let's start with that Microsoft was present on the market in 2004. In contrast, their market share has dramatically shrunk almost to non-existent by 2006. Second, Linux is yet again an important factor that analysts and more importantly phone manufacturers must take into account in 2006. Its roughly 40% market share is very considerable. Third, the strange thing is that Symbian's market share has remained intact during these two years - it's still around 60%.
- North-America: one of the strangest markets - at least from our analysis' point of view! In 2004, Palm phones were dominating the smartphone market (~50%). Their market share, though, has dramatically shrunk to less than half of their previous share (now ~20%). The same pattern can be observed with regards to the popularity of Symbian OS - but with different numbers. In 2004, Symbian was the second smartphone OS vendor dominating 30% of the market - in contrast they're now the fourth with their ~10%! Who won then? Surprise-surprise: Microsoft! They were the third most popular OS vendor in 2004 (~10%) and now they're the #1 with ~30%! The last observation is that RIM has pretty much gained position - they're the second now.
- Finally, the rest of the world (ROW): well, similarly to EMEA market Symbian phones are in monopoly.

As a brief summary my findings are as follows. Symbian's hegemony is noticable all around the world. In most places more than half of the smartphone OS market is in their hand(held)s. :) With one exception, though: North-America. There are couple of interesting articles (on SymbianGuru, Darla Mack's and Tommi's blogs) as to why Symbian, most notably S60 phones are not present in North-America so it wasn't surprising for me to see the trend. It came as no surprise, either, that Microsoft is just there in North-America - what I found interesting, though, that basically this is the only market where they are taken into account at all. Finally, it's already a cliche that Linux phones are coming. LiMo, MontaVista's Mobilinux and TrollTech are just a few keywords everybody blessed with a little foresight might want to memorize. Japan and China are two countries where experiments are being made with mobile linux - and their success seems to be tangible. But let's not continue the debate on which mobile platform is the best and more importantly who will win in the long run. On the one hand, that's impossible to predict, on the other hand it's worth another article. :)

Anything to add?

Migrated from Forum Nokia Blogs.

Tote

Symbian vs iPhone

I've found a link (thanks, Peter, for sharing) to an interesting article that details why iPhone's (and Apple's) OSX is better than Symbian OS and how it's going to beat it. I have some thoughts about the author's arguments, let me share them.

In most regards, Symbian's reputation as a modern, robust, stable and advanced OS for smartphones is not well deserved. Sure, Symbian works, it has a very long feature list, and it's probably even the best smartphone OS available today. But it's mostly because the competition is pathetic than anything else.

I must disagree with this statement. You might argue that the OS is not modern as lots of "not-so-new" features, such as STL, is not included, but this does not necessarily mean that it's not modern at all. How can you claim that the system is not robust, stable or advanced? How do you measure it? I don't think Symbian OS is worse in general than its competitors. On the contrary, I believe it's very robust and stable. Just an evidence: it can run for days, weeks without having to reboot it. Just show me another (preferably open) mobile OS that can do the same. And you mentioned that it had a very long feature list and the OS was the best today. Based upon all of this why do you say that the OS has not deserved to be the #1 OS for mobile phones?

The Three Symbians
From one point of view, there are no ‘Symbian’ phones in the market, but rather three incompatible and diverging OSs: NTT DoCoMo's Symbian MOAP for Asia, Nokia’s Symbian S60, and Sony Ericsson’s Symbian UIQ.

You're right and wrong. You're right that there is a very thick layer (S60, UIQ and MOAP) on top of the core Symbian OS that makes the three platforms incompatible at some extent. But you're wrong, because you can minimize the difference between these variants with some clever effort. For example, most engine components can be written with a common codebase. Which is not true if you compare different OSes like Windows, Palm, etc.

On the other hand, there's no better solution, I'm afraid. Neither Java nor Linux brings us the *ultimate solution*. And I'm sure it's clear for everyone why I'm not talking about WinCE here. Unfortunately, mobile OS market seems to be heading to divergence rather than convergence.

Finally, variation for iPhone and OSX is not an issue here as there is nothing to variate yet.

To make it even worse from a third party developer's point of view, Nokia and Symbian made the new S60 version 3 binary incompatible to previous versions of S60. So none of your old Symbian apps will work on any new phones (i.e. if you actually bought any :-).

You shouldn't be so cynical. Actually lots of phones have already been sold that are based on S60 3rd Edition. It's just one thing that you do not know it.

Symbian Signed
So much for independently third-party software development on Symbian compared to the ‘closed’ model used on iPhone. In practice the difference is not that big. Apple will, of course, allow close partners to develop apps like they do with iPod Games today.

"In practice", the difference is HUGE imho. In case you have not noticed, Symbian phones are not closed as opposed to (the almost) closed iPhone. I presume that to be a close partner of Apple will be much more difficult than to have your application Symbian Signed. And in lots of cases your application doesn't even have to be Symbian Signed - it all depends on what you want to use on the phone. You know, most applications are able to run smoothly with the most basic capabilities (or even without them) that do not require your application to be signed. I suggest you to take some lessons on how Symbian Signed works before judging it.

And you know, this is the price phone manufacturers have to pay to operators in order for their device to be sold. I believe it's still better than not being chosen as a 'close partner'.

Symbian Design Issues
... entire section ...

While I agree with you with regards to most of the technical issues you listed, I have one question: what do you expect from Symbian to do? Do you expect them to withdraw all those design decisions that they've made during those days when it was reasonable to make those decisions? You know, it's easy to criticize, but very hard to offer alternatives ... Not to mention the fact that it would most probably introduce another bunch of source/binary breaks in most programs. Obiously, it would be especially painful these days since we have not yet recovered from the shock of Platform Security. Instead, Symbian should make a smooth transition from old design to new (if it's reasonable), which will naturally take some time.

Analysts Wrong on Symbian
Most media in Sweden (and elsewhere) have reported that the iPhone is nothing new at all. It's mainly a nice package with limited/bad hardware and nothing particularly new on the software side.

Isn't that true?

However, if you look at the speed and effort needed to make new applications on iPhone compared with other platforms it's two completely different worlds.

I'm a little bit confused: does it make sense to make new applications for iPhone? Most probably you won't be able to install them at all.

Existing Mobile Platforms vs OS X
With Symbian (as well as WinCE, Palm OS, and I suppose also the Linux phones because they probably have a very limited number of Linux frameworks installed because of memory restrictions etc) you have a big problem to deliver on the marketing hype and media expectations because of all limitations. This is one of the reasons all mobile services are failing to badly—it's simply to hard and complicated to deliver the market expectations with today's platforms.

At this point I must admit that I have never used OSX (consequently never programmed for it, either). But regardless of that still wondering how OSX and iPhone overrule the rest of the mobile platforms?

Five Years Ahead
... entire section ...

Well, here I again must admit that I have never used Objective-C in my life. Thus, I can't make my own decision about this issue based on my own experience. What I have heard, though, from people who had used it is that it was very uncomfortable for them to use that language. And they felt sort of a freedom when they had changed from ObjC to C++. There weas no-one who told me that ObjC was (a) better (experience) than C++. Knowing that, is it really the language, the foundation, based on which a new mobile OS will rise and overrule the others? I don't think so, but please disprove me.


Nevertheless, I can see that you're right at some point. There're lots of things to improve, only a few examples:
- Documentation ==> developers spend a lot of time with browsing technical documentation. And it's by far not perfece/complete. One of the main (true) complaints about learning Symbian is that it has a very long learning curve. Although I think we're heading to the right direction (good examples in the SDKs, good and thorough books, trainings, forums, etc.) it still takes too much time for a beginner to get used to Symbian. We definitely need more better tools, for example, Carbide.C++'s UI Designer is another good step to the right direction. And Symbian and its stakeholders must realize it and take actions against it (I mean, the long learning process) in order for developers still to be motivated to write programs for Symbian.

- Tools ==> it's a cliche that there's no ultimate tool for Symbian development. What is even more painful that there is no single *free* tool that anybody could use with great benefit. For example, when Nokia made a political decision about not to support MS Visual Studio in their SDKs they should have already come out with a better alternative instead of MS VS. Not with CodeWorrier, of course. I believe that instead of investing so much money and time in CW Nokia should have turned to open source community sooner and then we would have a better, more stable and useful tool (Carbide.C++) by now. In my opinion, if Symbian and "their companion" want to give a boost to Symbian development, then they should provide/use free tools that simply work. Okay, it's easy to say, but still...

Migrated from Forum Nokia Blogs.

Tote

Do you think that PlatSec signing process is a nightmare?

Well, then let me share the following article with you about midlet signing. It describes how painful a Java midlet signing process can be. In addition to that, it also contains some basic information about how signing works (e.g. chain of certificates) and what it costs. Shocking experience. :-\

From signing and capabilities/permissions point of view I would say they're the same. You know, it's one thing that you've got to be familiar with a security system that sometimes simply doesn't work (unless you invest much-much money in it), the bigger problem that most developers suffer from is that you even have to pay for it. As security is our common concern wouldn't it make sense to introduce such a system in which nobody pays to nobody? You know, not only is the concern common, but the benefit would also be mutual. I know I'm so naive. :-\

Migrated from Forum Nokia Blogs.

Tote

Cost monitoring

I've started wondering just recently why there is no support at all for cost monitoring on our phones? Okay, on S60 phones there are two applications where you can monitor
- how much time you've spent with speaking on the phone,
- how much data you've up/downloaded.

You've spotted that neither tells how much money you'll have to pay at the end of the month, right?

Obviously, one of the main reasons why there is no such an application on your phone is that there is no such application on the market. Neither built in your phone. Is it that simple, huh? Not really. Let's think about it how our application should work:
- it either keeps track of how much time you've spent with speaking (you called someone or someone called you while you're abroad) and also monitors how much data you've exchanged (up/download, SMS, MMS, etc.).
- or connects to your operator's site and download data from there.

Let's examine these two options in more depth:
- Keeping track of everything on client side: it makes sense to do it as most of the required features are already present. I guess, at least as I presume here that the APIs Logs and Connection Manager applications make use of are publicly available. What is missing, though, the information that could be used to figure out the actual costs. Okay, the tariff could be retrieved from various places and eventually could be typed in into our fictitious Cost Monitor application as well, but first users are usually pretty much lazy to do that, second it's not even trivial to find out which rate we should apply when. For example, how do you know what rate to apply when you're abroad? You can't expect that the user will do all these operations as it's pretty much laborious. Even I would not do that. :-\ Not to mention the fact that even though it's kept track of e.g. how much data you've downloaded, but I doubt that I could figure out which bearer (e.g. 3G, WLAN) I used each time. As usually we use public WLAN service free of charge or pay for it when we're there, I wouldn't like to see those figures in my calculations. And I'm sure that there are other issues as well that we would need to tackle to get a correct end result.

Briefly: it would be pretty much challenging, if not impossible, to write such an application and even if it was possible it would put a big burden on users' shoulders to manage the application.

- On the other hand, if Cost Monitor application was only a thin client that could connect to the operator's site, then we could put all the burden of implementing the calculation logic on operators' shoulders (can you imagine an operator with shoulders?:). Which, in fact, has already been implemented as operators always know it pretty well how much money they can pull out from your pocket. I guess, some of you have already found it out that there is a little problem with this approach. Not implementation-wise, but from strategic point of view. And well, the problem is not only little, but HUGE: operators will never make such a service (e.g. a Web Services API) available publicly. It's simply not in their interest as it might inspire their clients (i.e. us) to have better control over their costs.

Finally, I did not go into details as to the features of our Cost Monitor application. The obvious one would be to give visual representation of the user's costs. A non-obvious, but very useful, one would be to be notified upon reaching/approaching a pre-set limit. I'm sure that everyone can immediately see why this feature would be opposed by operators - whose help we would rely on, btw.

Looking forward to your comments!

Migrated from Forum Nokia Blogs.

Tote