cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hu, Ningxin" <>
Subject RE: Pluggable webview design thread
Date Thu, 17 Jul 2014 18:05:01 GMT
Ian, thanks for open this thread.

Does the API design consider cookie sharing use case? For example, in current FileTransfer
plugin, it uses android.webkit.CookieManager directly. It will cause issue when using third
party webviews, such as Crosswalk.


> -----Original Message-----
> From: [] On Behalf Of Ian
> Clelland
> Sent: Wednesday, July 16, 2014 1:23 PM
> To:
> Subject: Pluggable webview design thread
> [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 earlier).
> 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.
> Ian
View raw message