Everything and the Mobile Software Universe…

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.

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!

After a huge AdobeMax in Los Angeles (more on that later, in another post and twitter), we’ve headed to San Diego for one day to look around this year CTIA, and attend the WIP Jam session.

Two words about San Diego: this city is GREAT! Go go Gaslamp! and the new Hitlon is just amazing…enough tourism.

Here are some bad shots (from by old iPhone 3G) about what we’ve seen:

Ok I admit, I have an iPhone. I love it,  blablabla you know the song already. It has its flaws, but as an old time mobile software engineer I’m really stroked by one BIG fact: The applications I use the most on it are fully web based!: My IM messenger (JiveTalk), my english/french dictionnary (Ultralingua), my mail and rss reader (special version of gmail and google reader) … even my all time favorite mobile game Bejeweled is web based!

What a shock I wasn’t prepared for that: when Steeve Jobs told us that the only way to add application will be (at first) through the web browser I was the first to laugh, only raw C++ is meaningful for applications, a web browser is a mere toy compared to a real application framework.

How wrong I was. And here is why. (and no it won’t be only about the iPhone)

• Unlimited and affordable data plan, and efficient bandwidth and coverage: I’m in Europe (France) and here network coverage and edge (2.5G) are very efficient.
• Webkit and Mozilla : Webkit engine tends to begin the defacto mobile web browser (check what pleyo is doing) embedded in S60, MacOS, Android…the only other credible contender is the Nokia Mozilla version (my Nokia N800 is simply unbeatable for web browsing).
• Raise of ad-hoc web services framework: the famous and numerous web widget frameworks (webwag being one to be noticed), and Yahoo GO for example.
• And the biggest one which is vastly under looked: modern websites, sorry webservices, are fully Model/View/Controller (ruby on rails, but above all struts2, etc.) what does it means in human readable language? : it is VERY easy to adapt the content/services of  a web site to different browsers / way of presenting data. Look at the plethora of “iPhone” optimized sites (ebay, dailymotion, facebook, etc)  that have popped up everywhere in few months.

Those approaches have something in common

• Need of a reliable wireless data link
• Well architectured network backend to provide optimized business data and adapted rendering data (the last one is not mandatory, check RSS for example were the business data has no notion of representation in it).
• An “On Client” web service framework: a browser with standard and added proprietary APIs like the iPhone Safari, a limited and fully proprietary engine like YahooGO, or a full OS with the complete stack like Android and … the iPhone OS (OK, don’t forget the “old” high level OSes like S60 and WinMobile).

Everything seems to be in place, and from what we saw above a good web service client platform would have to:

1. Be fun to use and compelling, tailored for each user
2. Be VERY efficient for the phone common tasks (phone call, address book)
3. Offer a nice and easy way to deploy data representation and flow control from existing web services backends…with good performance and relatively wide access to the underlying platform and datas

For me the first two doesn’t have to be understated (just try a WinMobile phone for a few months to understand what I mean ), as the device remains a phone, a communication machine and voice is still the undefeated champion for communication. This is where the iPhone is groundbreaking at a first sight…and also where I’m not sure of what Google Android will deliver (call me skeptical if you want…).

The third point may bring a lot of optimism … as it implies that we doesn’t need a single platform anymore, but a bunch of deployment possibilities, tailored for each devices/client or even each services . Android and  the iPhone may be seen as such a platform with at least two of those deployment possibilities: the browser and application native development, here Android is much more friendly to Java/Web programmer that the iPhone. But we could perfectly imagine devices with more deployment options or other completely different but close enough to web development standards to allow fast adaptation of web backends….why not an iPhone with an Android sandbox?

At the end the famous “cloud” (the network) is really shaping the “on device” clients, allowing more and more diversity and at there won’t be a “one fit all” solution…

Thanks Steve Jobs for being the first to have put in place all the elements of the chain, dealing with carriers, content provider, services providers…and coming with a great consumer electronic design.

Google wants to go further? not sure for now, but the US 700 MHz auction have to be followed very carefully cause if this spectrum becomes “free” of the carriers, we don’t know how fast it could go!