HTML5 is still one of the most discussed topics amongst us technical types. The key challenge, however, has remained unanswered for a long time. How do you effectively wrap HTML5 for use in native mobile applications? Unfortunately I do not have a universal answer, but I do have a solution for Android.
Firstly, I recommend looking into the use of Vellamo in order to benchmark the performance of HTML5 on Android (http://www.quicinc.com/vellamo/). Vellamo is designed to be an accurate, easy to use suite of system-level benchmarks for devices based on Android 2.3 forward. Vellamo began as a mobile web benchmarking tool that today has expanded to include two primary chapters: the HTML5 chapter evaluates mobile web browser performance; and the Metal Chapter measures the CPU subsystem performance of mobile processors.
I have my own custom architecture that extends RESS (Responsive Design + Server Side Components) called P-RESS (Performance RESS). The idea is to include performance based information inside the device family configurations. This means that an HTML5 based mobile client can query the RESS server to ask about the performance characteristics of its device family. This can be used to downgrade the graphical experience, for example removing a parallax scrolling background.
The big problem up until recently was that wrapping HTML5 into a WebView on Android meant that you had to use the default web browser, which unfortunately was not Chrome. Instead you ended up with the Android Stock Browser, which was a long way from Chrome. With Android 4.4 (KitKat) we now have the ability to use the Chrome browser through the WebView by default and this is very much welcome (https://developers.google.com/chrome/mobile/docs/webview/overview#what_version_of_chrome_is_it_based_on).
There are two downsides to this effort though:
- It only works on Android 4.4
- The WebView shipped does not have full feature parity with Chrome for Android (it is based on Chrome 30 as opposed to Chrome 33)
- WebGL (3D canvas)
- WebRTC
- WebAudio
- Fullscreen API
- Form validation
There is a subtle difference in marketing though: Famo.us claim to be building a better PhoneGap; whereas Ludei claim to be building something that is PhoneGap compatible. Both systems bundle the latest edition of the Blink engine (Chrome 33) with the App using a Cloud based build system. The two companies also have cool demos of WebGL running through a WebView on various Android 4 devices. This also means that when Chrome 34 arrives then it is presumed that could be bundled instead – depending on backward compatibility with earlier versions of Android 4.
Famo.us actually answer one of the key questions. Does each app have its own separately bundled edition of Chrome? Each time a Famo.us app needs a particular version of Chrome, that version is installed in such a way that other apps that need it can also use it – think shared libraries. At the moment the footprint for Chrome 33 is around 15-20MB but they predict the size will come down to 10MB. They can also have it not be part of the initial download of the app, but rather as an app upgrade.
It is unclear if Ludei will offer a similar shared library system at this time. One thing Ludei do mention is the increased portability and performance that WebView+ (as they call it) brings to the web environment. Ludei used to only offer support for games but just recently they added application support as well and this is when I really took notice of CocoonJS.
With one consistent HTML5 environment then it means the developers know the feature set to code towards. It becomes a sort of HTML5 Reference Implementation for Android. The minor downside is this only covers Android 4 and above. The major downside is this only covers Android. There is no way of bundling the latest version of Safari with an App on iOS and Windows 8 is even more problematic.
The other thing that Ludei and indeed Intel XDK offer is technology that cross-compiles HTML5 Canvas into OpenGL(ES) for Android or iOS. That means that if you are wrapping an HTML5 Canvas into a Native App then it makes far more sense to cross-compile it into Android or iOS native code. Ludei claims to have the fastest accelerated HTML5 Canvas, but Intel acquired similar technology from AppMobi. When Web Components become more widely supported then it would appear to be the next candidate technology to be cross-compiled into native code.
Oracle offers ADF Mobile which combines a Java VM with an HTML5 presentation tier, the benefit being totally portable plug-in extensions. Unfortunately when I looked into the solution there was no backward compatibility with existing PhoneGap plug-ins. Ludei has been clever here and made sure that PhoneGap plug-ins are explicitly supported and I am sure Famo.us will follow.
I had a chat with the W3C recently and asked if there was likely to be any standardisation in the following spaces:
- Control over hardware acceleration
- Mixing native code and HTML5
- Pure HTML5 deployable Apps
This means that outside of standardisation, we are going to need to be looking at a new gold standard for HTML5 based Hybrid Apps as follows:
- A Chrome 33/34 WebView for advanced performance, feature set and portability
- An HTML5 Canvas to OpenGL(ES) conversion for Native Apps
- PhoneGap backwardly compatible for existing plug-ins
*************************************************************
Kevin Benedict
Senior Analyst, Digital Transformation
Cognizant
View my profile on LinkedIn
Learn about mobile strategies at MobileEnterpriseStrategies.com
Follow me on Twitter @krbenedict
Browse the Mobile Solution Directory
Join the Linkedin Group Strategic Enterprise Mobility
Join the Google+ Community Mobile Enterprise Strategies
***Full Disclosure: These are my personal opinions. No company is silly enough to claim them. I am a mobility and digital transformation analyst, consultant and writer. I work with and have worked with many of the companies mentioned in my articles.
