Hybrid Applications(web apps within a Webview container):
These apps are installed on a device, like their pure native app counterparts, while the user interface (UI) is based on HTML5. This UI runs locally within the native container(Webview), which usually leverages the device’s browser engine. The advantage of using HTML5 is a consistent, cross-platform UI that works well on most devices. Combining this with the native container, which is installed on-device, provides mobile users with access to local device services, such as camera, GPS, and local device storage.
We are using HTML5 today to build rich, interactive web pages (or web apps) then you’re already familiar with the benefits of using HTML5 as a tool to deploy across multiple browser and OS platforms. Cross-platform apps built on HTML5 are a logical extension to this model, where the platform is not a browser (such as Chrome*, Safari* or Firefox*) but the internal web runtime (aka webview) on the target platform.
HTML5 apps are not limited to web pages viewed in a browser. You can also package your HTML5 code and deploy it as a locally installed hybrid web app. This enables use of the same distribution and monetization channels as native apps, as well as the same installation and launch experience. Rather than running within a sandboxed browser window frame, your app runs in a full-screen webview, with full control over screen real estate and device capabilities.
Hybrid Architecture Concepts & Fundamentals :
Hybrid Applications consist of native code that creates an embedded web browser used to
render parts of the application user interface which are written in standard HTML, JavaScript
and CSS formats.
The actual browser engine used within the embedded web browser and it’s configuration
options are provided by the device operating system vendor. The browser engine’s
implementation changes between versions of the operating system, usually the same browser
engine technology is kept and just a newer version of the browser engine is used when an
O/S is updated, but sometimes completely different browser engines are used in newer
versions of the O/S. Across different operating systems, completely different browser engine
implementations are used (eg. WinPhone8 – Internet Explorer/Trident, Apple iOS – Safari/
Webkit), even though they may be based off of the same underlying browser engine codebase.
Even if an operating system provides a specific browser engine, parts of the browser engine can
be replaced by carriers (that have forked the primary O/S for their devices or markets). A good
example of this is Webkit, which has replaceable subsystems that are implemented differently
on different operating systems (eg. iOS, Android, Blackberry).
It’s also important to realize that the embedded web browser engine used inside the webview
native code of the hybrid app often has different capabilities enabled from the default
standalone browser application provided by the mobile operating system vendor. There is
no guarantee that the browser engine used by the default browser will have exactly the same
features and runtime characteristics as the browser used by the embedded webview API
provided by the same O/S vendor and version. As an example, see the next section about
Android’s browser engines changing in different versions of Android O/S.
The Android browser
Which one do you mean?
Traditionally Android provides a rendering engine based on WebKit called the WebView. The Android browser — simply called Internet — uses the WebView. But other browsers and any application that need to render HTML can use it too, including apps that have been build using web technologies with PhoneGap.
Unfortunately the standard WebView is pretty bad. It has quite a few rendering issues and missing support for established web standards. And because the Android browser uses the WebView it too has been pretty bad. The last major update it got was with Android 4.0.
That is why vendors have actually started making ‘improvements’ to the WebView they ship on their phones or tablets. They took the open-source WebView and made quite a few improvements. But also introduced quite a few new bugs and other issues. Sometimes they just enabled features that were deliberately disabled in the standard WebView, because the current implementation was not yet ready for public use. Sometimes they started using updated version of WebKit. And sometimes they implemented new features on their own, but almost nobody shared the work they did on the WebView and contributed it back to Android itself.
So we ended up with devices that use the standard unmodified WebView and devices that use their own modified version. As a result you can take 5 different phones using the same Android version and end up with 5 different HTML5test.com scores. This is a complete nightmare if you want to test your site or webapp on Android. If your site works with a particular version of Android on one phone, there is no guarantee it will work on another with the same version. Let alone on a different version!
The Android browser is still relevant
The common wisdom is that with recent versions of Android, the Android browser has been replaced with Chrome. While this is true on Nexus devices, this is certainly not the case for other devices.
The open source version of Android does not include the Chrome browser and still uses the old Android browser. And almost all non-Nexus devices are based on the open source version. I haven’t found a single non-Nexus device that does not have the Android browser in one form or another. And even if Chrome is pre-installed, the Android browser is often still the default browser.
And even if you have a Nexus device without the Android browser, the default WebView is still there. Any application that wants to render HTML still uses the default WebView and does not care if Chrome is installed or not.
Even more variations
So we have the Android browser which either uses the default WebView or one of a dozen modified versions of the WebView. But we also have another variation we haven’t covered yet.
Every Samsung device released after the Galaxy S III uses an improved version of the default WebView. This includes the S4 and later, but on these more recent devices the Android browser does not use the WebView anymore. What Samsung did was modify the Android browser so it can use the rendering engine from Chromium.
The first version of this new Android browser was used on the S4 and all of its variants.This first attempt is based on Chromium 18 and as of the Note 3, it has been updated to use Chromium 28.
On the Galaxy S III, the Tab 2, Tab 3, Note 8.0, Note 10.1 and many others we have the following rendering engines:
• the modified WebView — used by the Android browser
• Google Chrome (not installed by default on all)
On the Galaxy S4, S4 Mini, S4 Zoom and S4 Active we have:
• the modified WebView
• the Android browser which uses Chromium 18
• Google Chrome itself
So on the Note 3 and Note 10.1 (2014) we have the following rendering engines:
• the modified WebView
• the Android browser which uses Chromium 28
• Google Chrome itself
Just one more complication: it seems like Samsung is even shipping different variants of their Chromium 28 based Android browser. The Note 3 does not support the WebAudio API, while it is available on the Note 10.1 (2014).
Which HTML rendering engine does the JellyBean WebView use ?
(http://bricolsoftconsulting.com/jellybean-webview-html-rendering-engine/)
We often work with hybrid Android apps that have both native code (written in Java) and web code (written in HTML /JavaScript). When we do, we often need a quick way to test whether the HTML component works properly. Typically, this means loading the HTML in a mobile browser. If the HTML loads successfully and renders correctly, then the HTML should also work in the app’s webview.
When we do this kind of testing, we try to make sure that the web browser employed for testing uses the same HTML redering engine as the webview. On Android versions up to JellyBean, this means using the classic Android browser, which according to Google shares the same rendering engine as the webview. On JellyBean though, with Google’s introduction of the Chrome browser and with some talk about a Chrome-based webview, things got a bit murky… Does the JellyBean webview use the Android Browser or the Google Chrome rendering engine? Which browser should you use to test your HTML on JellyBean?
To get a definitive answer to this question we are going to dive into the Android codebase. For that, we will turn toGrepCode, a site that lets anyone quickly browse multiple versions of the Android OS codebase without needing to download the multi-gigabyte source code repositories.
We begin our search in the source code for Android 4.2.2 r1, which can be found here.
Since we’re interested in the WebView class, let’s find that class in the source code. We know from the Android documentation that the WebView class is located in the android.webkit package. You can browse to that package and open the WebView.java file.
What we find :
private static final String DEFAULT_WEBVIEW_FACTORY = “android.webkit.WebViewClassic$Factory”;
private static final String CHROMIUM_WEBVIEW_FACTORY = “com.android.webviewchromium.WebViewChromiumFactoryProvider”;
As you can see from these last two code snippets, the default WebView provider is still the “classic” webview that is based on the Android Browser rendering engine. Apparently there is work underway to switch the webview to the Chrome rendering engine, but right now that’s only available in debug Android builds using a special flag.
Based on an examination of the Android source code, the webview does not use the Chrome rendering engine in Android 4.2 (JellyBean). The webview is still powered by the Android Browser rendering engine.
Android WebView History
Currently, there are the following versions of Android in the marketplace:
Here Comes Chromium
As you can see from the table above, in Android 4.0, the platform’s default browser application
changed from an Android webkit fork to use the new Chromium engine based on Blink.
Chromium (the same browser engine that Google Chrome’s desktop browsers are based on)
supports more HTML5 features and has better support of many of the same features that were in the Android Default browser engine.
Android 4.4 makes it even more complicated
With the release of Android 4.4, Google has replaced the default WebView with a new WebView based on Chrome 30. While this may not have much impact on Nexus devices — it already uses Chrome as the default browser — it does matter to vendors that still ship the Android browser.On those devices the Android browser will suddenly be using the rendering engine from Chrome 30, which is an enormous improvement.
THE GOOD NEWS
Finally we have the ability to debug remotely Android native webviews –including PhoneGap apps- and the Android Browser and it works smoothly both from real devices and from the emulator. When we have an Android app opened with a web view or the Android Browser, the Chrome remote debugger tools will recognize it as a “Chrome 30” session and we have the full package of excellent tools for debug, profile and test our webapps.
For more info :
https://blogs.oracle.com/fusionmiddleware/entry/developer_s_corner_developing_mobile
http://www.smashingmagazine.com/2013/10/17/best-of-both-worlds-mixing-html5-native-code/
https://software.intel.com/en-us/html5/articles/building-cross-platform-apps-with-html5
View at Medium.com
http://www.mobilexweb.com/blog/android-4-4-kitkat-browser-chrome-webview
globetrotter 