cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ian Clelland <>
Subject Pluggable webview design thread
Date Wed, 16 Jul 2014 20:23:18 GMT
[Opening this discussion up on the list, as it had previously been the
domain of private conversations and limited-audience discussions]

On the 4.0.x branch, we're developing an API for pluggable webviews. With
Cordova-Android 4.0.0, we are going to be providing a reference
implementation, "AndroidWebView", which uses the system webview, and should
be externally identical to the webview provided by Cordova 3.x (and

The API is going to be made available for third parties to implement
compatible WebViews against, such as Crosswalk and GeckoView. Since third
parties are going to be coding against this API, it will be difficult to
change once released, so we'd like to get it right the first time.

This email thread is about defining that API, and getting consensus so that
we can start to stabilize the 4.0.x branch.

In the interest of backwards-compatibility, and of feature-parity with
previous releases, I think that these things are important (but are all up
for discussion):

 - The AndroidWebView implementation should be (i.e. java:extends) an
actual android.webkit.WebView, for the sake of existing applications which
assume that this is the case.
      - New webviews shouldn't have that restriction, since they *aren't*
android.webkit.WebView's, there's no reason for them to extend one.
      - Because of Java's lack of multiple inheritance, this kinda means
that CordovaWebView needs to be an interface.

 - It was previously possible for a subclass of CordovaActivity to provide
a makeWebViewClient and/or makeChromeClient method, to override the default
construction of these objects. This is a public API, for users who have
specific needs from their webview, and we should maintain that.
      - By default, those methods should just defer to the instantiated
WebView to create its own client objects ("do the right thing"), but it
*should* be overridable by the application developer to provide whatever
objects are appropriate for *their* application, without having to hack on
the webview code.
      - It's okay that app developers would have to know the concrete class
of the client objects they are creating. It's their app, and they know what
engine they are choosing to use.
      - Making CordovaActivity "do the right thing" by default does involve
some complicated logic in CordovaActivity and the engine WebViews, but I
think it's worth it.
      - Before commit 'efcedabe', this was previously implemented.

I'm going to write up the actual API as I see it being implemented, and
then we can discuss that to. I'll post it back to this thread.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message