Gabor Torok's Forum Nokia Blog

Transforming mobile industry

Thu, 16 Oct 2008 16:44:30 +0200

I read the following quote from Olli-Pekka Kallasvuo, Nokia CEO, in InformationWeek:

"The industry as whole is in the middle of a transformation, and it's a very exciting time," said Kallasvuo. "It's moving from a device industry to an experience industry, and we're making a conscious long-term effort to capitalize on that."

It is so true that it inspired me to write a summary on how things have changed in the "smarter" segment of mobile sector (read:smartphones) lately. Let me recap what was the situation in the near past and then talk about how things are changing recently.

In the classic device manufacturer - network operator - user triangle the roles were as follows (simplified version): user purchases mobile phone from network operator (or elsewhere) and uses those services that are primarily provided by the network operator. The manufacturer never gets any money after purchase and the user is often unhappy with the content/quality of provided (value-added) services.

This is now about to change. The two most important changes (as I see it) are that 1: the above triangle is "rectangularized" by an old/new member of the value chain, a separate content/service provider and 2: that device manufacturers such as Nokia and Apple OR operating system vendors such as Microsoft and Google want to get money after sales, too: they'd like to enter services business. As to point #1, not as if content providers hadn't been present so far, however, the means to access content and the capabilities of devices have not been ideal so far to say the least. As for point #2, there are two reasons why manufacturers would like to enter services business (take it over from operators?): first, there's a great demand from users to consume content that operators have not been good at providing and second, there's great money in it. Apple and Google are very good at providing services now they'd like to be involved in adding new means (i.e. phones) to accessing their services. Whereas Nokia and Microsoft are both in a strong position in smartphone market and naturally they'd like to get more money out of the whole business.

Another aspect in the new business model is whether or not shall mobile OS vendors require license fee for their software to be included in shipping devices. I'm talking about free and open-source mobile OSes, like mobile Linux. Although mobile Linux stacks have not gained so much popularity in the past years, they still do attract manufacturers wishing to lower their bill-of-materials (BOM). Google Android and the new Symbian (Foundation) OS are another two good examples for "license-fee-free software stacks" and Windows Mobile is for fee-based. iPhone's Mac OS X cannot be mentioned here, since Apple doesn't allow anyone to license their software stack, but make everything on their own.

How do mobile OS vendors pamper their developers?

Of course, with a free SDK to develop on. Most of them can be used only on Windows (except iPhone on Mac OS X), true emulation is available on Windows Mobile and iPhone, where development is done on the same platform as the target platform,
Free tools for development. Unfortunately not everything can be done with these tools, but you have to pay for their fee-based version should you need to use more advanced features (e.g. on-device debugging in Carbide.C++),
Signing your own installation package is mandatory for both iPhone and Nokia S60 phones, but not on Windows Mobile and Android. Latter advocates that the user is always capable of making proper decisions on security-related questions and it does not restrict the availability of 3rd-party applications by requiring signature. As Symbian's David Wood put it: let's see what operators will say on it.
As to developer support, old players are in the best position here: there's a great community support for Windows Mobile developers as well as materials to train themselves. The same is true for people who are developing for Nokia phones. Whereas the first non-beta Android SDK has just been introduced (you can imagine the level of support Google provides at such an early stage), not to mention Apple who wanted developers to sign an NDA that essentially prevents free information flow, writing books on development, etc. This has changed recently, since Apple finally scrapped their iPhone NDA and promised a new contract with less restrictions. Note: if Apple hadn't made this step they would have lost the majority of their developers.
Developers reward programs (MVP from Microsoft, Forum Nokia Champion program from Nokia), fee-based support for ISVs willing to pay for advanced services, webinars, trainings, books, etc.
Stores to capitalize on applications, themes, etc.

As to the stores mentioned above,

Apple's (in)famous App Store acts as a central distribution channel for 3rd-party applications. Unfortunately, Apple keeps this place under such a strict control that bitters lots of developers' life who simply don't understand why their programs can't be sold just because they're similar to the built-in applications. On the other hand, Apple keeps only 30% of revenue making App Store more compelling than lots of rival portals, such as Handango.
Having introduced T-Mobile G1 a few weeks ago, Google has also thought that it was a wise idea to create their own Android Market, a market place for downloading Android applications. What is surprising, though, is that Google is not planning to capitalize on sold applications, but expects mainly freebies to populate this place. It wouldn't be Handango if they didn't make the best out of this situation: why not use Handango to get some money for your Android app? It's also worth noting that Google, similarly to Apple, will be able to remove any 3rd-party applications (downloaded from Android Market) from Android-powered handsets if those applications turn out to violate developer distribution agreement.
Nokia already has their Software Market, however, things might change with the start of Symbian Foundation next year: as Antony Edwards from Symbian put it "[they're] pushing hard for a ensuring a zero, or a close as possible to zero, cost to the software vendor: so no cut of revenue for the Foundation".
Finally, Microsoft hasn't maintained their own single portal that ISVs could use for selling their 3rd-party applications, but people had to (and still have to!) use other providers. This article shows what one can conclude from job postings: with the coming of new devices based on Windows Mobile 7 a new portal, SkyMarket will also come in Q1 2009.

Nokia is very keen on transforming from being a device manufacturer to an "internet company". Their Ovi and Mosh are two examples of already launched services, which they just want to further improve with Instant Messaging (by buying OZ Communications) and Comes with Music. On the other hand, whilst strengthening their services portfolio they restructure their businesses so that they focus less on own product development (selling Nokia IntelliSync). Sometimes lowering the prices raises the revenue - wonder how the recent price cut will work out. It's especially important that since more and more people own Nokia devices, it increases after-sales revenue, too.

I've been already thinking on what Microsoft's reaction will be to open source and then found the answer: Steve Ballmer doesn't understand what's good in open source for Symbian and Google and anyway they won't get into handset business as long as they can make a lot of money from software only.

What they've started to work on lately, which you might have already heard of in the news, is 'Windows Cloud' OS. This idea is not new at all, however, it might affect the way how people use their mobile phones today: all you need is a portable device with a tiny display, some computing power and a good browser (you can call it 'smartphone') plus a good connection to the "cloud". Data, business logic, resource intensive heavy computation - all done on remote server(s) and you get only the result to your handset. I wrote 'this idea' was not new, however, what is new is Microsoft's patent on sharing device resources. Now this one is really new, but I don't know how much I can expect from it in real life - what it shows you, though, that it would be too early to write Microsoft off. Side-note: let me recommend you Ajit Jaokar's thought-provoking blog on how network operators could make use of cloud computing.

One more point to add to why M$ is not to enter the handset business today: HTC, designer & manufacturer of feature-rich phones, says that although they can see the potential in Android devices they do belive that Android and Windows Mobile complements each other.

As to Android, it's amazing to read about the ambitious plan to reach 4% US market share by the end of 2008. If that's so easy with a single device, a not perfect software and hardware AND suppose that they will achieve it - may I ask how on Earth Nokia could not do the same?

Anyway, I found a great analysis over at Telco 2.0 on the strategic impact of Google's first handset on the mobile industry. I especially liked the statements, such as "increasingly intense competition with new entrants who are willing to change the rules" and "the world in which handset manufacturers crammed the latest technology into devices simply for the sake of having the best specification sheet and operators flogged them to consumers on the basis of megapixels and memory is changing" and finally "it has been fascinating to watch ‘old school’ industry commentators pick apart the technicalities of the G1 spec sheet and Android platform, all the while forgeting to look at this announcement through the customer’s eyes".

Finally, some words about other members of the mobile industry whom we don't hear much about (well, at least I haven't lately).

Sony Ericsson has rationalised their R&D investment recently. This move, however, didn't prevent them from announcing a new run-time environment, called Capuchin, mixing Java ME and Adobe Flash Lite technologies. SE is eyed-up on Android, too, not only Windows Mobile (Xperia X1) and Symbian so this along with Capuchin will make their way to follow Nokia's approach by offering lots of alternatives for mobile software development.
Motorola is also interested in Android, so much that they are building-up a team of 350 people to develop on Android.
Samsung is not interested in anything else but manufacturing. This will not make their position stronger in today's competing market.

That's all for now about mobile industry news, thanks for reading so far!

All comments are welcome,

Tote
mobile-thoughts.blogspot.com

Browser as an application platform

Thu, 19 Jun 2008 01:10:10 +0200

I've read the following analysis from ARCchart with great interest. I'm already familiar with the idea of writing applications for mobile browsers and that it can be considered as a real alternative for mobile software development. WidSets and Widgets are all around us, not to mention Flash Lite, Silverlight, two cross-platform solutions used for delivering (multimedia) content to more and more people.

The main point of ARCchart's article was to point out that the whole problem of fragmented mobile development could be solved by developing to a single run-time environment: the browser. The browser, which is today's most widely used applications on desktop and mobile computing devices alike.

What is this fragmentation thing, one could ask? Well, let's have a quick look at various mobile platforms, development environments:

It's a known fact that Symbian/C++ opens the door to the wide variety of native features of S60 and UIQ devices, however, it still has a steep learning curve and its programming environment is not too developer-friendly, either, compared to e.g. Java. The vast majority of smartphones are running on Symbian operating system (whether iPhone-fans admit it or not), however, development is often more (cost-)efficient for other platforms. Portability is a serious issue in Symbian.
Windows Mobile devices are very popular in North-America, especially among business users. However, its popularity is way behind Symbian phones' anywhere else in the world and don't forget the fact that there are much more consumers than prosumers. On this platform, you can write native applications in Win32/MFC/.Net, however, these applications are rarely portable across other platforms.
Java? Hell, it's the king of fragmentation in terms of supported (or rather unsupported) features, so-called JSRs. Even though it was supposed to bring the Paradise to mobile software developers, it's still suffering from severe problems.
What else? Linux? Show me some popular Linux-powered phones first and how people are making cross-platform, backward compatible programs for them.
iPhone? Mac OS X with its Objective C just increases variation. Even though C++ can also be used for programming and there are, for example, attempts to port JME programs to Obj-C, as I said: it just increases variation, which is the nightmare of programers.
Android? Although the whole system is based on mobile Linux, the primary development language will be Java. But which Java? Google's own. And although it's said to be a solid foundation for Google OHA members, it's still only a recommendation for them to choose whether various features will be supported in their devices or not. You can imagine how it affects fragmentation in the Java world - it will just make it even more complex.

Now how does a browser come into play? I'm sure that most readers of this blog have already heard of WebKit, an open source browser engine enabling mobile browsers to show and handle full-web content. It is used in Mac OS X's Safari (iPhone browser), Nokia's S60 browser, the built-in browser of Google's Android will also be WebKit-based, not to mention Digia's @Web, a recently announced port of WebKit for UIQ phones. Although there are other good browsers, too, such as Opera Mobile and IE in Windows Mobile, WebKit seems to be becoming the de facto standard in mobile devices (which is not necessarily a bad thing). It's also worth mentioning Opera Mini and TeaShark at this point, two Java-based browsers, both using remote back-end servers for pre-processing full-web content and showing only the digested content formatted for resource-constrained devices. Side-note: it's also WebKit that is running on TeaShark's back-end servers. :)

So is ARCchart right or not? Is the browser the ultimate solution for mobile software development? In my opinion yes and no. They're right that mobile browsers and complementing technologies (such as Flash Lite) are becoming more and more powerful, capable of rendering extremely complex web pages, performing surprisingly smart functions, letting the user interact with active content, exchanging data with remote servers, etc. However, whilst "older" web technologies (e.g. JavaScript) are not powerful enough to compete with the power of real programming languages, newer ones (e.g. Flash Lite) have not been widely adopted yet. For example, for a quick and very brief reference as to what the different versions of Flash Lite can and cannot do, visit this link. And even though there's not too much variation here yet, there will be: newer versions of Flash Lite will require developers to keep track of which mobile phone supports which version, how to distinguish between Silverlight and Flash Lite applications, etc. I'm afraid it won't be any different in the end.

In my opinion, web-based technologies will open up new alternatives (they've already done so, actually) for mobile software: not necessarily too complex ones, but at least enjoyable. And this is exactly what most people are looking for: they'd like to enjoy using these programs. These new kind of programs that complete the whole picture, add to it, but will NOT replace yet older but still powerful technologies.

Can hardly wait for your comments,

Tote

Android SDK is out - first impressions

Tue, 13 Nov 2007 03:15:17 +0100

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! :)

Originally from mobile-thoughts.blogspot.com.

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.

Symbian development - An alternative to embedding applications

Sat, 20 Oct 2007 17:01:42 +0200

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!

Originally from mobile-thoughts.blogspot.com.

Tote

Random thoughts on web browsing in S60

Fri, 20 Oct 2006 14:36:06 +0200

As I was involved in the development of S60 browser for years, I think I have a good overview on how a mobile browser works. Therefore I'm particularly interested in the "mobile browser war" taking place in S60. First of all, I'm surprised that there's a _war_ at all.

Of course, I'm talking about Opera and the new S60 (or OSS) Browser. You know, I'm a big fan of the latter (for reasons, see above) and I think it's a fantastic piece of software. I see that there are lots of other people around the world who share my opinion. Nevertheless, I still don't decline using other similar software, like Opera, just because it's not my favourite. Even more, I don't understand why supporters of either browser hate the other software and argue endlessly protecting their favourite. Hey, it's a free world, anybody can like anything and no need/place for hate.

It's just because both browsers are good. Extremely good in a not-so-easy environment! Whilst OSS Browser (any official name of this software?) is strong in showing web pages in their original layout, it's often found as a weakness, too, when the user has to scroll sometimes a lot in order to navigate to the relevant part she's interested in. Opera solves this problem by rendering the web page smartly (I mean, knowing that it's going to be displayed on a smartphone) so that it always fits on to the screen horizontally and even if the user has to scroll she has to do it only vertically. However, small screen rendering ™ has a drawback: the layout of the web page is changed and it's sometimes not what the author of the page wants and/or the users like. I think this is the main difference between these two fantastic browsers and it's really up to the users which one they prefer knowing the pros and cons. I personally bow to scrolling a bit more, but expect to see the page in its original layout, thus vote for the OSS browser.

But as to Opera Mini, Opera Software's free browser: I bow before them! To those who still don't know, Opera Software has written two different browsers for mobile phones: Opera and Opera Mini. So far I've been talking about the first, but I must tell some words about the latter, too. You know, I have visited Opera's boot on Smartphone Show and had a short chat with one the guys there. Besides that they share my opinion on the opposition of these two browsers, I heard some technical details about Opera Mini from them. First, it's not written in Symbian C++, but Java programming language. I was surprised to hear that as browsing requires as much resources (memory, CPU, I/O, network) as possible and the Java run-time environment is not famous of providing this as it would be desirable. But to my biggest surprise, it turned out that Opera Mini turns to an Opera server first asking it for downloading and rendering the web page in question on behalf of the mobile phone. I guess, the second step for Opera Mini is to download and show the "pre-digested" page information (not confirmed, though). That's fantastic! I mean, I'm amazed of how they could come out with such a brilliant idea. They can even apply compression techniques on the pre-digested data so that they reduce the amount of data to be transmitted to the minimum. Very cool! It's unnecessary to tell you that I've already downloaded and taken Opera Mini into use on my Nokia 6630. To my biggest pleasure - also unnecessary to say. What? - I hear. Yes, I'm using Opera Mini on my Nokia phone as the built-in browser is not good enough to my needs (OSS Browser has not been backported to older S60 versions).

Finally, as I've already written, I have attended Google's Q&A session on Tuesday. I was not surprised when they applied the common formula and said that "we're going to port/write as much software for Symbian in as short period as possible". I mean that's natural, it's certainly in their interest, too. Nevertheless, I started to think whether it's really worth for them to write software for S60 at all. Provided that the built-in browser is already close to perfection (just close, though), users of advanced S60 phones can enjoy almost(*) desktop browsing experience. Thus, no need to write anything for this platform! However, in the (*) section I wrote "almost" and I did it on purpose. You know, a mobile phone with such a small screen, never-enough memory, slow(er) CPU will never be able to beat desktop browsers, in my opinion.
Side-note: interestingly enough, I was not there when Nokia had announced their vision on the Smartphone Show that new mobile phones would slowly replace even desktop computers in the not-too-far future. Having mobile phones used for almost a decade, I would never have predicted it to happen. Tell me, when will you want to stare at a small display 1/20 (or less) in size of a desktop display? Or type in long documents with an ITU-T keypad?
So, it's Google's interest to make their services available on Symbian, too. Fortunately (and due to the fact that they're smart enough), their APIs enable anybody, not only them, to make this happen in a relativel short period. I can hardly wait until they announce their LBS-supported Froogle! :)

Any comments?

Tote

Update: I was wrong when I wrote that it had been Nokia announcing mobile phones replacing PC in the near future. Mentioned in Michael Mace's great article, it turns out that it was Symbian. And don't forget to read the comments, too: I also share Steve Litchfield's opinion that we don't have to over-react this announcement. :)