Mailing-List: contact dev-help@cordova.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cordova.apache.org
Received-SPF: pass (athena.apache.org: domain of agrieve@google.com designates
 209.85.223.171 as permitted sender)
MIME-Version: 1.0
Sender: agrieve@google.com
In-Reply-To: 
 <CAK_TSXKnKQcyPzEcQ8HyFXqyJ8Cx-LdNCU220nqRd_H9dyq95Q@mail.gmail.com>
References: 
 <CAK_TSXKnKQcyPzEcQ8HyFXqyJ8Cx-LdNCU220nqRd_H9dyq95Q@mail.gmail.com>
From: Andrew Grieve <agrieve@chromium.org>
Date: Thu, 17 Jul 2014 11:21:42 -0400
Message-ID: 
 <CABiQX1XnRswyOgH2NQQfdM1oMYUOVPQ2nHSjJ7tOrXZRsUPJYA@mail.gmail.com>
Subject: Re: Pluggable webview design thread
To: dev <dev@cordova.apache.org>
Content-Type: multipart/alternative; boundary=089e0115f46eea655d04fe6533bc

--089e0115f46eea655d04fe6533bc
Content-Type: text/plain; charset=UTF-8

Thanks Ian! Probably a good idea to discuss the heck of this.


On Wed, Jul 16, 2014 at 4:23 PM, Ian Clelland <iclelland@chromium.org>
wrote:

> [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.
>

There are two clients that I think we need to consider:
1. CordovaActivity
2. Plugins

Plugins are the more important case I think, because using plugins doesn't
mean you understand how to edit your java. For CordovaActivity however, I
think so long as we are backwards compatible with the default template,
then other changes are more fair-game because they affect only developers
who have some understanding of Java anyways.

For AndroidWebView extending WebView, I don't see how doing this helps with
backwards compatibility.

Both CordovaActivity and Plugins hold a reference to the webview as a
CordovaWebView interface, and so the inheritance structure of the
implementing class is unknown to them. E.g. They would need to explicitly
cast CordovaWebView -> AndroidWebView to exploit the fact that it extends
WebView. Might as well have the call .getView() so that their code works
with any WebView.


>  - 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.
>

So - reason I think these functions don't make sense: they only apply to
when the WebView is an AndroidWebView. Each engine has their own set of
helper classes. What we *could* do is:
 - Use an instanceof check to see if the webview is an AndroidWebView
 - Only if it is, call these make*Client() functions

However, I think this is a pretty confusing thing to have these hooks if
they apply only to one engine.

Instead, subclasses can override makeWebView() and hook up whatever Client
subclasses they want as a part of that (or do any other initialization of
it that they want).

This means if anyone has overridden the make*Client() methods now, they'll
need to update their code, but if this is the case, then we're dealing with
people that already understand how to write Java, and the change is quite
mechanical.


>
> 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
>

--089e0115f46eea655d04fe6533bc--