Everything and the Mobile Software Universe…

Perhaps you don’t know, I’m the Tech Lead of the ELIPS Studio Product (feel free to try it for free here!) . For those of you who have already jumped on board, I really hope you enjoyed the first releases we have posted …and you have as much fun playing with it as we have building it!
We are pretty busy right now bringing some exciting stuff to the table, like, well, as promised the iPhone.
I just wanted to share with you the approach we have selected, and the path we are following.

iPhone : Widgets and the runtime part
We have decided to follow a different path than for the other platforms regarding widget handling.
As you all may know the S60 and WinMob widget toolkits are well, pretty dated and replacing it by some modern flex widget is a definitive plus. But in the iPhone case, this is the opposite, the iPhone has a very comprehensive, modern and user friendly widget toolkit, with physics, hardware acceleration, etc…and Apple requires you to use it to pass its dreaded Appstore approval.
So we had two choices here:

1. Redeveloping, in Flex the iPhone widgets so applications will  “as much as possible” look like real iPhone ones, or ..
2. Mapping the Flex UIComponent widget tree directly to real iPhone widgets to leverage the platform strength

The first solution has its advantages, like code reuse accross platforms, consistency when developing in the simulator vs a real phone opposed to the second one which is requiring a much bigger porting effort, impossibility to precisely simulate the application, BUT when you do an application at the end, it really feels like a real Objective-C one, following iPhone standards … but coded in AS3.
So yes we’ve taken the hardest path: we have followed the native widget route … and we are pretty happy about that
The biggest issue with such an approach is for us, not for you: this is the porting time.  We have to map all the iPhone widgets with their yet to be created MXML counter part and implement those new MXML widgets in a generic form (read pure AS/MXML) for the other platforms.
Today the iphone list is mapped, meaning that you simply have to declare a list with your own item renderer, data provider everything you know and love … and it will look and behave like a real iPhone list, with its unmatchable physics and hardware acceleration for smooth scrolling. Look at the following video for a very simple list with an item renderer in Flex and a data provider …no iPhone code at all but a real iPhone list anyway

Text entry (in place and not in place) is ported too.
Of course all the “normal”, non mapped widgets are working well and can be completely and transparently mixed with the native mapped one: you won’t notice the difference.
And we are at  that point: Shall we release it to let people try it even though a lot of widgets are not mapped? Or shall we work a little bit more to map all  iPhone widgets?

iPhone : the toolchain
As you have noticed, for now, our tools are Windows only (just to let you know I’m writing this article on my Mac ). Perhaps as you know too from our documentation we are compiling the MXML/AS to C++ for the applications, but also to develop our runtime and libraries: for the iPhone we have simply used our compiler and tools to generate a bunch of C++ files from our Flex SDK, alongside an XCode project then we transfer it to a Mac and we are able to build a fully native iPhone application, right from XCode, running in simulation and on device with C++ debugging….sweet.
In that case, for the application developer,  the flow is:

1. Develop in FlexBuilder With ELIPS Studio plugin on a PC (or better on a Mac, in a Windows VM, like Parallels, my favorite, or VMWare)
2. Generate the C++ files from your MXML/AS with the ELIPS Studio build button
3. Put this source tree on a Mac (if you were working on a VM … simply put it in a shared folder of your VM)
4. Open it in XCode, build, simulate, debug, deploy on the Mac

Of course in parallel we are working on a full Windows only toolchain, based on one of the patented unique OpenPlug technology: platform independent software components (used today in our WinMobile and Symbian platform and on Android also, oups, yes I’ve said that too look at the video , exact same list code as in the iPhone video, but in “Flex Only” mode, no natif mapping, pure MXML/AS for the list implementation:

Look at the performance on a G1 ).

Bottom line, we are wondering if it makes sense to release the current hybrid toolchain, or in the contrary wait for the integrated one.

iPhone : the next steps … tell us what you think!
So here we are today:  we are able to release an iPhone technology preview, with a limited set of native widgets, and an hybrid toolchain.

Beside this, the iPhone roadmap is pretty clear (and we are already progressing on it):

• Complete the UIComponents mapping to have all the iPhone widgets available
• Complete the Windows only iPhone toolchain
• …Port our tools under Mac, at least for iPhone development

I hope those insights helped you understand how our iPhone support will be completed, and I really would like to have your point of view and comments (either via twitter, in the forum or in this blog post):

• Are you willing to try our first shot for iPhone dev, with its limitations (very few native widgets)?
• Are you ready to develop in such an hybrid environment?

We need your feedback!

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