Everything and the Mobile Software Universe…

For long (see my article about the industry ecosystem) OEM have heavily relied on ODM for production and many times design of their phones…except Nokia which has historically preferred to keep everything internally to manage cost, scaling, distribution and above all margins, but kept around 20% of its production in the hand of tightly controlled ODMs,

In 2008, Nokia outsourced about 17 percent of the manufacturing volume of its mobile phone engines, which include the phone and software that enable its basic operations.

Nokia’s key subcontractors have been Foxconn (2038.HK), China’s BYD (1211.HK), Jabil Circuit (JBL.N) and Elcoteq (ELQAV.HE).

via Reuters

certainly to balance its risks and not put its internal factories and staff exposed to a high demand slow down from the market. This is happening today.

And Nokia:

Nokia Pulls More Than $5 Billion in Business From Contract Manufacturers

via iSuppli

We’ve seen some signs already with this Foxconn announcement:

Foxconn Full-Year Profits Drop 83%

Foxconn International Holdings – the mobile phone manufacturing division of Taiwan’s giant Hon Hai Precision Industry has reported a net loss for the second half of last year, which dragged its full year profit down by 83.% to US$121 million – compared with US$721 million a year earlier.

cellular-news

And those industry moves:

TAIWAN ODM handset maker Arima Communications and EMS provider Elcoteq have temporarily set aside merger talks in favor of joining forces to produce low-cost handsets for LG Electronics, company sources told DigiTimes.

DigiTimes

SAN JOSE — Flextronics has reportedly laid off about 70 workers in Taiwan and additional cuts are possible, according to a local newspaper report.

The Apply Daily, citing company sources, said most of laid off workers are from the company’s notebook and server operations.

Flextronics acquired the Arima notebook and server business operations in March this year.

CircuitsAssembly

Arima is the big SEMC ODM, and is really hurt by SEMC woes.

When time are tough, sub contractors are the first to be cut, but when economy is rising again they are the first to get the benefits: if they were able to survive. Let’s watch at this space to look at the first sign of recovery!

Thomas

A good UI  is nothing without talented graphical designers and interaction designers: How  the plethora of new UI technologies are helping unleashing their creativity? What are the main concepts behind those technologies?  Let’s try to find out!

UI is trendy… thank you MacOS X, Vista and iPhone!

Put the designers in the application development driver seat!

Here is a little slide about the actors involved in UI design

Read the rest of this entry »

Found at All About Symbian:

Red Five Labs has just announced that their Net60 product, which enables .NET applications from the Windows world to run unchanged under S60, is now available for beta testing.

.NET on S60 3rd Edition now a reality?

This is really interesting: even the battle for languages/execution environment is not settled.

For years Mobility coding was tightly coupled with assembly code, then C and in lesser extent C++. The processor of choice is the ARM family (ok some others exist, but no more in the phone industry)…this was before Java.
Basically Java (the language) is no more than a virtual processor with its own instruction set, and this virtual processor, also called a Virtual Machine, or JVM in the case of java, simply do what every processor do: it processes some assembly code describing the low level actions to be performed by the processor to execute a given program/application.

On the PC other execution engines have been developed: the first obvious one, the native one is the venerable x86 instruction set: thanks to it all the PC applications are “binary compatible”. Then Java also, and more recently … the Macromedia/Flash runtime (yes Flash is compiled in a Byte Code which defines its own instruction set). An other big contender is the .NET runtime…with you guessed what, its own instruction set.

At the end it is easy to categorized the executions engines:

• The “native” ones: the hardware executes directly the actions described in a program, compiled from source code to a machine dependent format. A native ARM application running on a ARM processor is an example, or partially for a Java program that is running on an ARM with Jazelle (some Java byte code are directly implemented in hardware)
• The “virtual” ones: Java, .NET, JavaScript/Flash (or ActionScript, not so far from JavaScript: the two languages will be merged with the next version: ActionScript 3 == JavaScript 2 == ECMAScript 4) where the source code is compiled in a machine independent binary format (often called byte code)…But how an ARM emulator running on an x86 PC may be called? you guessed, virtual.

So why bother with virtual execution engines?
Java has been built with the premise of the now famous (and defunct ) write once run everywhere, because at that time (and I really don’t know why) people were thinking that it was enough to reduce the “cross platform development issue” to the low level binary compatibility, simply allowing the code to be executed. And we know now it is not enough!

Once the binary issue was fixed, the really big next one were APIs (and to be complete the programming model) … and the nightmare begins. When we say Java we only name the Language, but not the available services, same for JavaScript, C# or ActionScript. So development platforms started to emerge CDLC J2ME .NET framework, Flash, Adobe Flex, Silverlight, Javascript+Ajax, Yahoo widgets … but after all what are GNOME, KDE, Windows, MacOS, S60, WinMob ?…yes development platforms.

The Open Source community has quickly demonstrated that binary compatibility was not that important for portability: once you have the C/C++ source code and the needed libraries plus a way to link everything, you can simply recompile for ARM/x86 or any other platform. Hum I’ve made a big assumption here: you have “a way to link everything”. And this is really a big assumption: on many platforms you don’t have any dynamic link, nor library repository or dynamic service discovery…so how to expose cleanly your beloved APIs?
This is why OSGI has been made, like COM, Corba, some .NET mechanisms, etc : all is around component based programming, encapsulating a code around what it offers (an API, some resources) and what it uses (API and resources).

Basically an execution engine has to:

• Allow Binary Compatibility: Abstracting the raw hardware, ie the processor, either using a virtual machine or a clean build environment
• Allow clean binary packaging
• Allow easy use and exposition of services/APIs

But it seems impossible for virtual engines to dissociate the language(s) and the engine: Java …well for Java, ActionScript for Flash, all the # languages for .NET. An execution engine is nothing without the associated build chain and development chain around the supported languages.
In fact this is key as all those modern languages have a strong common point: developers do not have to bother with memory handling, and as all the C/C++ coders will tell you it means around 80% less bugs, so a BIG productivity boost, but also and it is something a tier one OEM told us: it is way more easy to train and find “low cost” coders for those high level languages compared to C/C++ experts!… another development cost gain.

A virtual execution engine basically brings productivity gain and lower development cost thanks to modern languages ….. we are far far away from “write once run everywhere”

But as we have seen before it is really not enough and here comes the real development environments based on virtual execution engines :

• .NET framework platform : an .NET VM at hearth, with a big big set of APIs, this is what I would like to know what are the APIs exposed in this s60 .NET port
• Silverlight : also a .NET VM at hearth + some APIs and a nice UI framework
• J2ME: a JVM + JSR + …well different APIs for each platform
• J2SE: a JVM + a lot of APIs
• J2EE: a JVM + “server side” frameworks
• Flex : Adobe Action Script Tamarin VM + Flex APIs
• Google Android: Java VM + Google APIs,… but more interestingly also C++: as android use Interface IDL description C++/Java interworking will work (I have some posts to do about it)
• …and the list goes on

So at the end what really matters is the development environment as a whole, not simply a language (for me this is where android may be interesting). For example the Mono project (that aims to bring .NET execution with Linux) was of few interest before they ported the Windows Forms (Big set of APIs to make graphical stuff in .NET framework) and made them available in their .NET execution engine.

What I haven’t mentioned is that the development costs gain allowed by modern languages comes at a cost: Performance.
Even if Java/.NET/ActionScript JIT helped partially for CPU (Just in Time compilers: VM technology that translates virtual byte code to real machine code before execution), it is still not the case for the RAM used, and in the embedded world the Moore law doesn’t help you, it only helps to reduce silicon die size, to reduce chipset cost, so using a virtual engine actually will force you to … upsize your hardware, increasing the BOM of your phone.
And it isn’t a vague assumption: when your phone has to be produced in the 10 millions units range, using 2MB of RAM, 4MB of flash and an ARM7 based chipset helps a lot let you make money selling at low cost….we’ve spent some nights/days optimizing stuff to make it happen smoothly very recently

At OpenPlug we have built a nice execution engine, not virtual, running “native code” on ARM and x86, with an easy to use service discovery mechanism: a component platform for low cost phones. Then we have added a development environment with tools and middle to high services….we have learned big time and sometime with pain all the bricks needed for such an environment! …

A key value may be around one framework and multiple execution engine for easy adaptation with legacy software and productivity boost for certain projects/hardware, or some parts of the software.

Because once you know how to cleanly make some code running independently from the hardware, you have to offer a programming model! Implying how to share resources between your modularized pieces of code…and in that respect execution engines are of no help, you need an application framework (like OpenPlug ELIPS, or Hiker from access, Android is about that, but also S60 and Windows Mobile): it will abstract the notion of resources for your code : Screen, Keypad, Network, CPU, memory, … this is another story, for another post!

Please comment!
Thomas