cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Bowser <>
Subject Re: [Android] Third Party WebView Reference Implementation
Date Thu, 02 Oct 2014 16:02:12 GMT
Response inline as usual:

On Wed, Oct 1, 2014 at 6:04 PM, Andrew Grieve <> wrote:

> On Wed, Oct 1, 2014 at 4:53 PM, Joe Bowser <> wrote:
> > On Wed, Oct 1, 2014 at 1:18 PM, Andrew Grieve <>
> > wrote:
> >
> > > On Wed, Oct 1, 2014 at 11:07 AM, Joe Bowser <> wrote:
> > >
> > > > On Wed, Oct 1, 2014 at 7:24 AM, Andrew Grieve <>
> > > > wrote:
> > > >
> > > > > Good idea (I think)!
> > > > >
> > > > > In my mind there's two main things wrong with our current
> > abstractions:
> > > > > 1. WebView plugins should extend a class instead of implement an
> > > > interface.
> > > > >   - Reason: You can't make *any* changes to an interface without
> > > breaking
> > > > > the compile for everyone that implements it
> > > > >
> > > >
> > > > Reason we use an interface: Java does not support multiple
> inheritance.
> > > > Both Ian and I have said this numerous times, and you wishing that
> this
> > > > wasn't the case isn't going to magically make this change.  This is
> the
> > > > only way this feature is even possible.  Also, this is an API that
> > we're
> > > > designing, and we shouldn't be messing with the interface.  We're
> stuck
> > > > with a lot of WebView-isms that may not even make sense on
> non-Chromium
> > > > webviews, but I think the surface has been decreased.
> > > >
> > >
> > > I don't think we need multiple inheritance. What would you want to
> > inherit
> > > from?
> > >
> >
> > AndroidWebView inherits form WebView, and the Mozilla WebView that I'm
> > working on inherits from GeckoView.  They both can be used as their own
> > views, and most of our tests still work.  By removing the interface and
> > saying that things aren't views anymore breaks the WebView feature that
> > we've worked on two releases ago that some people still use.  Sure, you
> > don't use it, and you have made it clear that you don't care about these
> > users, but we need to have some sort of consistency.  I'd rather have
> > people just rename a class than lose an entire feature because you don't
> > think it's important.
> >
> I think my concern here is similar, so let me try an give some examples:
> - 3.0.x has CordovaWebView as a class that extends WebView
> - 4.0.x has CordovaWebView as an interface.
>   - Any code that previously used CordovaWebView as a View or a WebView
> will no longer compile, since CordovaWebView is an interface. Even though
> AndroidWebView extend WebView, the type system doesn't know that. You could
> update your code by casting to an AndroidWebView explicitly to fix the
> compile errors, but then you're losing out on the 4.0.x ability to use
> different WebViews.
>   - What we did was add a getView() method, which you should use to get at
> the actual android.ui.View class in a WebView-independent way. Yes, this is
> a breaking change, but it's broken in the same way interface or not.
So, I'll magically call this in my XML layout! It sounds to me like you
haven't actually looked at how people used the CordovaWebView feature.

> Any embedder or plugins that assumes CordovaWebView is a WebView (or a View
> even) will not compile anymore with it being an Interface. Making it a
> class doesn't fix this either, but it does allow us to add new methods in
> the future without breaking things. True, we could create a new Interface
> each time we wanted to change it (CordovaWebviewV1, CordovaWebViewV2, etc),
> I think that will be a lot more complicated than following the pattern that
> we use for CordovaPlugin (a base class that we can add to, but not remove
> from)
Have you ever embedded a WebView? Part of the feature is that you only have
to do this in the layout:




        android:layout_height="fill_parent" />

Then in the Activity, you find the view by ID and initialize it normally:

        //CB-7238: This has to be added now, because it got removed from
somewhere else


        cordovaWebView = (CordovaWebView) findViewById(;

        cordovaWebView.init(this, new CordovaWebViewClient(this,
cordovaWebView), new CordovaChromeClient(this, cordovaWebView),

                Config.getPluginEntries(), Config.getWhitelist(), Config.
getExternalWhitelist(), Config.getPreferences());


You don't need to fiddle with layouts, or find the parent and somehow
attach it or do any other things that you would have to do with Cordova on
an Android Layout.  If you can do this with your configuration, then it's
all good, but currently I don't think you can.  That's why I said you
should spin up a topic branch.  I'm not saying "spin up a topic branch"
just to be an asshole, I'm saying it because some things are easier to
figure out when you actually try and code it, and I can't read minds over
the Internet.

> I'm sorry you feel this way. I assure you I have no secret agenda. I just
> want the design to be as maintainable as possible. I did a good amount of
> work on 4.0.x a while ago, that's what made me think that the design is not
> quite right yet. I may be wrong, but I don't remember any sort of approval
> happening for this.
So, there's two branches with this functionality in our git.  There's
pluggable_webview, which has had no work done on it in four months, and
there's the 4.0 branch where we started to merge in the pluggable_webview
work.  I remember this being a big deal because we had to make sure that
all the ICLAs were signed.  Also, we talked about exactly this on April
30th with the multiple inheritance.  The thread is called: [Android] Not so
fast....API changes in Cordova-Android for Pluggable WebView

I'm having trouble finding the e-mails about merging things like the
pluggable_webview, but we definitely discussed it and felt it was ready to
go into the 4.0.x release branch, which was basically our holding area for
things that are stable enough to be released but breaks the API.  Pluggable
Webview was merged into there May 29th, which tells me that we spent the
entire month of May either playing telephone or we actually did talk about
whether this should or shouldn't have gone into the release.  The
frustrating thing is how this design was gone over by everyone, but is
still totally wrong, and yet we don't have a better feature branch.

So, can you implement what you're saying and still keep the thing working
on a topic branch? I can't see how that would be possible, but again I
can't magically read minds over the Internet, or through anything else for
that matter.

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