Everything and the Mobile Software Universe…

Despite all what can be read everywhere, Nokia is still an incredible company:

• They have a formidable supply chain (and you have when you are selling arounf half a billions phones a year)
• They are the only phone brand who is making money from emerging countries
• They have an incredible story of reinventing themselves from paper factory to wheel, TV set, phones and network equipments, now why not services?

For me they have everything in hand to succeed and stay the undisputed leader. Even if lately Nokia has been under fire, with its first loss in ten years, they are actively pursuing new ways to recover

• Services startegy, with a lot of acquisitions around OVI (Dopplr, Plazes, Navteq, Trolltech, Symbian, Plum, cellity, etc. See this url for a full list: Nokia acquisitions)
• Hardware differentiation: netbook (nokia booklet 3G)  and widening Intel cooperation (check my article around this here)
• Software consolidation to allow common deployment accross the 3 Nokia’s device software platforms: S40 for low-end phones, Symbian new S60, called Symbian^4 and the next Maemo 6

The last point was, for me, the best way to make OVI appstore a success, to allow developers to target hundreds of millions of phones, then billions in few years … and Nokia didn’t and won’t, for now, deliver it, here is why:

The first part is in this “Nokia Software Strategy WhitePaper” from December this year (2009), found at Nokia Hosted Presentations :
The following graphic speaks for itself:

S40 development will be limited to java:

• no Web runtime, so no webkit, but we are talking here of low cost phones, low data throughput,  low CPU, low RAM so this is not a big surprise (WebKit is not exactly an embedded browser)
• NO QT!  j2me is here for a while…

This is pretty clear : Nokia didn’t manage/want to open-up S40 with an externalizable SDK, and this is a big surprise! For the little story OpenPlug has made it for the very very low cost SonyEricsson J132, just to say that it is possible.
So what happened? Political internal war? Lack of vision? Lack of resources?  I bet on the first one, Nokia is such a big company that refocusing and putting energy in a single direction is really difficult.

It doesn’t stop here : Nokia is developing two incompatible UI frameworks on top of Qt, one for Maemo 6 and one for Symbian^4. So, as a corollary, there is NO chance that a Maemo application will be Symbian^4 compatible without a complete rewrite of the presentation layer, bad news for the developers.
To have all the details, check this thread and this thoughtful post: Maemo 6 loosing source compatibility with plain Qt, and Symbian^4, to sum it up, here is what happened:

1. Qt is an “old generation” UI framework with WinXP like normal widgets, no animation, no fanciness
2. A QGraphicsView has been added to allow the creation of animated and fancy widget, like the iPhone ones for example
3. BUT : no standard widgets has been created on top of it
4. The Nokia Memo team has created its own set of new generation widgets called Maemo Direct UI (Maemo DUI)
5. …and the Symbian team also! for Orbit now called 4 Symbian^4 UI framework.

So here we are, to add a simple button, a list or a table or any UI building blocks, a developper will have to use different APIs to do the same thing, once for Maemo, the other for Symbian, aleviating nearly all the Qt advantages and promises for UI commonality.

What I believe the Symbian and Maemo teams in Nokia need to do now is get together and fix this before it’s too late

Mark Wilcox

And I can’t agree more…they have to fix it before releasing it to the wild.

Again political fights, point of views, and over engineering seem to be the root cause of this non-sense, but perhaps also the Nokia DNA : Nokia is building products, not platforms (if the S60 licensing failure and application development nightmare is any indication of it…), and this is an area where they really need to reinvent themselves if they are serious about their services strategy.

Of course OVI appstore won’t fall apart because of this Maemo/Symbian split, but it will bring more hurdles to application developers, so less applications, and less innovation to the Nokia platform. S40 remaining closed is a much higher subject of concern, as it really looks like a missed opportunity. For the first time I do think that Samsung with Bada (check my article here) has a more pragmatic and comprehensive platform software strategy than Nokia (times are changing…).

Any comments?

Recently Samsung announced Bada, a new development environment: in a nutshell this is an SDK with a set of C/C++ API associated to an application framework, ported on top of Samsung legacy RTOS, or Linux.
Bada will be deployed in a majority of Samsung touch phones from smartphones to feature phones.
Antony has been quicker than me and posted a nice Bada article at Vision Mobile, depicting why this Samsung move may prove to be a wise one. I mostly agree with him, his arguments are around gross margins, market pressure and differentiation. I’ll try to dig a little more around this differentiation aspects in the Samsung case and why they really seem to innovate in this area, especially versus an Android strategy.

When Bada was announced, I was very negative, my first reactions and comments were harsh: again a me too initiative from Samsung, the OEM with fantastic execution but no clear vision of its services/software strategy, trying all the available OS on the planet and waiting to see if one is successful.
Then I’ve looked back at what they achieved recently and what they’ve announced with Bada.

• They are now the undisputed number 2 in number of devices sold (not far from 20% of the market in Q2 2009 for ex)
• The Touchwiz UI 3.0 is on the smartphones AND ALL the other touch phones of the company: difficult to tell who is or is not a smartphone now (I’ve made the experiment at the last CTIA).
• Release of the Touchwiz UI widget SDK to develop widgets for all the Touchwiz based phones.

What are they trying to do with this TouchWiz UI ?: use the best software platforms (RTOS for cost effectiveness and integration, high level OS for SDKs and features) while trying to uniformize the user experience and consolidate the Samsung brand.

Obviously the next step, to retain its customers, a politically way to say “lock them in”, is to have exclusive applications and services accross the Samsung devices line…even better if the customer has paid for it so he won’t throw away its application investments to buy a competitor phone for its next purchase. Same strategy as Apple, but here we are talking about Samsung a company with dozens if not hundreds of different device models, across all the price ranges, selling more than 200 millions phones a year (yes a year! how many iPhones sold today? , ok margins, blablabla…and yes I have an iPhone).
How to do that? Make a robust application environment, OS agnostic, with a dedicated SDK, to allow deployment of the same binary to a range of devices with different software platforms … well this is exactly the description of Bada.
We (speaking in the name of OpenPlug in this sentence only) have advocated this very same idea for the last 7 years to push OEMs in this direction (Samsung and Nokia were part of the lot ), and this is at the end taking of : Nokia with Qt (still has to deliver but the intention is clear) and Samsung with Bada.

But why creating a new one and not simply reuse Android code base?…I’m sure you have the answer already:

• Android is free? Android is by no extend free: you have to pay a lot of your R&D budget to make a phone with your brand, your services, etc…
• Android is open, why not getting it? NO Android is a closed box, Google and only Google can really change it, it’s really time for the industry to wake up: it’s not because you have the code of something that you can control it. If you don’t have the roadmap and the team who is maintaining and developing it you simply have meaningless mega bytes of symbols
• …but this is from Google, the good guys! Sorry, they are not, they are pushing their own services, not yours, and now with the NexusOne their own phone and user experience.

Google/Android has a complete opposite aim versus OEMs own agenda:

• Android is here to push Google services in the mobile world, as a corollary it allows you to swap your device as easily as possible because the new one will have all your data and applications loaded and compatible from the old one.
• … wait,wait this is exactly what an OEM doesn’t want: an OEM wants you to buy your next phone from them, not the competitor. So you have to differentiate.

Samsung, like Nokia, simply doesn’t want that an external third party software house decides if its devices has to be like that or like this… to be look alike brothers to its direct competitors (check the Windows Mobile phones for the last 5 years, and you will get the point : all the same).
So why not following their own path? Apple has made the choice and is successful, Nokia is trying, Samsung has to move, and for me it is doing so in a more pragmatic way than Nokia:

• Bada is not about reinventing a new OS with the underlying plumbing to the hardware as is Nokia Mameo, who cares of that today?
• The User Experience is already in production and refined device after device
• Bada SDK is not “fancy” but raw C/C++ … but what the point as long as I can sell and do my applications for hundred of millions of devices and customers (let the fun to the WebOS guys…I’ll get the cash)

Of course Bada is not quite their today, where are the devices? where is the market place? But it is refreshing to see Samsung taking its own path, its own direction…opening even more opportunities to application developers.

This DevX article: Get to Know uSTL: A Lightweight STL for Symbian describing a symbian STL (C++ Standard Template Library, the C++ “toolbox” with lists, vector, string utils, etc.) less crippled that the standard one, really reminded me of this eternal debat.

Recently we have worked on some memory optimization for our product, the part running on the PC. It was using way too much memory compared to what information was effectively loaded.

The data model is XML, and we are creating our objects with SAX parsing of this model… and many things were stored in STL string, and some stream where used….surprise STL string where using 128 bytes preallocating data…so for a 4 bytes string you use …. 128 bytes! stream memory use were growing exponentially!

So we played brut force and quickly reimplemented a class string based on good old char *, and a stream tuned for our use…and guess what: mem usage was divided by 10, and it was really faster.

Conclusion of this story: if you want to go serious, you have to master and well understand all the objects you use heavily: It may sound obvious, but many many time programmers take too many things for granted, especially on the PC world ….you know why Windows is now using way too much RAM …but in the PC camp Moore Law helped a lot to deal with RAM/CPU power explosion…

It is not to say that STL is a bad library (ok, not so intuitive to use, but it is another story), but those kind of services are ok for prototyping, or “normal” application, not for intensive ones. The difference between this two kind of applications is blurry, and coding something faster prevails way too often, heading to crippled apps.

Now look at the mobile phone space, here the Moore Law is not bringing a lot of RAM/CPU, it is “only” bringing down the chipset cost…but the vast majority of mobile phones are still running on CPU with less that 10 MIPS and 256 or 512kB of RAM, BUT feature sets are still growing and growing….

So obviously your applications, services, HAVE to use less RAM and less CPU each time, hum we are really NOT in a PC world.

To achieve that you can:

1. Continue to code as close as possible to the bar metal (uhm silicium), using low level C code, assembly, few OS services.
2. Use a Mobile Phone coding framework, taylored for the embedded space (this one is itself made using the previous point mode of programming), with a native programming language (C/C++)
3. Use a Higher Level OS with a native programming language (C/C++) (Palm, WinCE, Symbian)
4. Choose an “interpreted framework” like Java or .NET (see the Mono effort in this respect)
   
5. Go for scripting. (like OpenLaszlo, Ruby On Rails, Digital Airways, etc)

Of course the more abstract you go the more RAM/CPU you loose, but the more developper productivity you get … if you stick too closely to the PC world mantra. BUT if it doesn’t fit in your target …. it won’t fit , and you loosed a lot more that productivity, you loosed your market.

A high Level OS is simply not a choice: try to fit WinCE in a 10 MIPS machine … it is already not snappy on a 400MHz ARM 926 … (same for Symbian and in less extent Palm)

So things have to be more balanced, and as the zen approach told us “the middle way” may be the solution.

I strongly believe that a mix of very high level services for UI, with a good interconnection with low level services for control, algorithm and modelling part of the application is the way to go:

1. You let the graphists/designers quickly design your UI
2. You code the algorithm, controls, threading model, network in C/C++ with low level or very low resource consumming APIs
3. You let the framework dealing with interactions between applications and resource access sharing.

The last point is crucial, else you end up with a big mess, with unmaintenable and non evolutive code cause all the services will have to know each others, definitively a big mistake. The first one has to be there cause clearly the UI is, in this market, defined in specifications by UI specialists, and it can greatly improve the time to market to let them “design to manufacture” with some powerfull tools to create UI, like user friendly RAD, or even better like Flash Lite SDK, or Digital Airways But those high level solutions are not enough cause they lack the second point: the logic of your app have to be done in a scripting language, which is clearly not tuned nor designed to do that: UI and Logic HAS TO BE more clearly separated to use the best tools to do the job.
Java also doesn’t fulfill those needs … SavaJE is not everywhere, no phone with full Java UI…(I won’t go also in the Java mess around standardization, check this techtype entry about internationalization ): It is not good for UI (only a programmer can do a UI), and so so for application core (CPU and RAM, plus missing APIs).

For sure, as said at TomSoft we need Mobile Developement Simplification(and yes widget standardization can help), but the traditional vision of “one model” fits all seems clearly not relevant for our industry, and more innovative frameworks have to emerge to trully allow the explosion we are all waiting around mobile services (see this entry about skype failure to deliver…).

What do you think?

Update: Taken from the Adobe Flash Lite 2.1, here are some RAM/CPU for flash …

Ok, we are far from the “Ultra Low Cost”/”Low Cost” segment but not by a 10 factor (except for CPU), so suing only some part of flash for a phone UI is not out of question ….

Update 2: Good read at “C. Enrique Ortiz Mobility Weblog” about the C language, and why it is still, and will stay, usefull. Anyway for me C++ is also a “low level” language as it is compiled and you are dealing yourself with pointers …

GSM Association Press Release 2006 – GSMA announces shortlist for the first Asia Mobile Innovation Awards We are really proud to be part of this shortlist!