Editor’s note: We offer our long-term sponsors the opportunity to write posts and tell their story. These posts are clearly marked as written by sponsors, but we also want them to be useful and interesting to our readers. We hope you like the posts and we encourage you to support our sponsors by trying out their products.
In a blog post published last week entitled “Cross Platform Mobile,” Martin Fowler argues the case against cross-platform mobile application development tools. While his analysis is spot-on, his conclusion fails to hit the mark. Done right, cross-platform mobile application toolkits offer developers the very best of Web and native apps in a single location.
Sponsor
In his post, Martin takes lessons from the failed promises of “write once, run everywhere” cross-platform desktop technologies like Java (one could also add Flash into that bag – remember Steve Jobs’ “Thoughts on Flash“?).
His analysis can be summarized as follows:
When dealing with the differences in user experience between platforms, cross-platform technologies can adopt two different strategies – emulation or abstraction.
The abstraction approach involves hiding the native UI controls below a “meta-API” (e.g. Java’s SWT) that stays the same across platforms. The drawback of this approach is that it has so far resulted in a watered-down experience providing only the lowest common denominator between environments.
On the other hand, emulation relies on reproducing/mimicking the native UI controls (e.g. buttons, lists with momentum scrolling, fonts etc.) in a virtualized layer (e.g. Swing classes inside the Java VM or SenchaTouch javascript libraries inside a Webkit HTML5 browser or Flex Actionscript components running in the Flash player/AIR). The drawback of this approach is what Martin refers to as the “uncanny valley,” i.e. repulsive end-user perception of the inevitable slight differences from “the real thing.”
No disagreement there.
However, Martin’s conclusion that one should forego cross-platform approaches entirely, and either go full native – at the expense of development resources – or full Web – a deliberate, radical departure with the device’s native user experience – ignores a third, more practical option. In fact, Martin alludes to this option in the final footnote of his post:
“I see one path that might prove me wrong. In this scenario you use a cross-platform toolkit – but you write a different app, with a different experience design, for each platform you build for.”
This is the exact approach Alcatel-Lucent has taken with its OpenPlug Studio cross-platform toolkit (which the company acquired in the fall of 2010 to bolster its Application Enablement strategy and released free to developers last week). OpenPlug Studio allows mobile and tablet app developers to create native apps from the same high-level code base (in Javascript or Actionscript), then use conditional compilation directives and assets packages for platform-specific features and UI layer components. As a result, mobile and tablet application developers end up building multiple binary variants for each platform from the same source tree.
The benefit is obvious (in Martin’s own words):
“The gain over doing this with native code is that you have a single platform for your developers to use and can get some reuse of common code (particularly non-UI code).”
Martin also offers a couple caveats with taking such an approach – each of which is capable of being overcome.
“This strategy doesn’t address the problem of dealing with UI controls.”
… it doesn’t?
It’s actually possible to map the underlying native UI controls into the higher-level programming space of the cross-platform toolkit. In the case of OpenPlug, native UI controls from iOS, Android, etc. are mapped into a namespace extension of Adobe’s Flex MXML UI layout declarative language.
When’s it time to compile, native code is generated that links to the underlying UI libraries of the device OS, e.g. Cocoa Touch on iOS or the Java UI classes on Android. The result is that when a List component is built, iOS receives the real scrolling list in all its glory (momentum scrolling, physics/rebound and all), while Android receives a list reflecting that platform’s behavior.
And all of this…in a single line of code!
Sure, there are functional differences in the implementation of a given UI Control (say, List) between platforms. But these can be managed by providing an exhaustive set of control properties (the superset of each platform). With conditional-compile directives for each platform, a smart cross-platform mobile app compiler will then include or exclude specific attributes where applicable.
This represents the exact opposite of a “lowest-common-denominator” approach.
And OpenPlug isn’t the only one doing this. Similar approaches have been adopted by Novell’s MonoTouch (high-level binding is C# in their case) or Appcelerator’s Titanium (ditto in Javascript).
“Even if it works, it’s only worthwhile if the developer-understanding and code reuse benefits are significant.”
This would be true if the high-level language of the cross-platform toolkit were proprietary or didn’t have a large following. With modern and relatively “standard”/well-adopted high level languages like ActionScript (or C#, or Javascript), there is a significant mass of developers already trained in using the language and associated frameworks to tap into.
Moreover, a significant body of reusable components, in many cases open source, also are readily available for numerous under-the-hood core functionality, such as network API wrapper libraries for Twitter, oAuth…take your pick.
This combination of a smart cross-platform technology and a well-adopted, high-level language yields benefits an order of magnitude higher than going pure native app on each device or pure Web app on all devices.
Can you build something that combines the best of the Web and the best of native apps? Yes, you can. Simply:
- Avoid replicating your dev team for each new platform.
- Don’t do plain dumb “Write-Once Run-Everywhere” with an emulation of native UI.
- Use a smart cross-platform native app development tool like those mentioned above.
By Guilhem Ensuque, Director of OpenPlug products at Alcatel-Lucent. @gensuque_op
Photo by 第③ª类视觉
0 Responses
Stay in touch with the conversation, subscribe to the RSS feed for comments on this post.