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.
-ningxin > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of Ian > Clelland > Sent: Wednesday, July 16, 2014 1:23 PM > To: [email protected] > 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
