cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Bowser <bows...@gmail.com>
Subject Re: [Android] Third Party WebView Reference Implementation
Date Wed, 01 Oct 2014 20:53:44 GMT
On Wed, Oct 1, 2014 at 1:18 PM, Andrew Grieve <agrieve@chromium.org> wrote:

> On Wed, Oct 1, 2014 at 11:07 AM, Joe Bowser <bowserj@gmail.com> wrote:
>
> > On Wed, Oct 1, 2014 at 7:24 AM, Andrew Grieve <agrieve@chromium.org>
> > 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 it's unrealistic to think that we'll never want to add any methods
> or parameters to the interface.
>
>
And this thinking is why Cordova is so terribly unstable, and why quality
has gone down since 3.0.  For all the talk about not changing APIs and not
screwing over our users, you seriously managed to do exactly that with your
refactors that you did on master without using a topic branch.  That's
exactly why we had to re-do the tag at 3.6.4, because Marcel and Martin ran
into problems with your refactor.  This is the line in the sand, this is an
API that we want third-party people to use, we can't keep making changes to
it in minor versions.


>
>
> >
> > 2. We need to reduce the amount of copy & pasted code between the
> > > implementations.
> > >
> >
> > Given that this is literally the AndroidWebView that exists in the 4.0.x
> > repo ripped out, this is copy and pasted code so that it actually works.
> >
>
> To clarify: I think the distinction should be "what code is specific to my
> webview" vs. "what code is specific to any webview within Cordova". And
> right now there's a good amount of Cordova-specific code in the cross-walk
> and AndroidWebView code.
>
>
There's a lot of code that needs to be in a WebView for Cordova.  This is
because of the numerous use cases, such as multiple WebViews, where each
instance needs to keep track of its own set of plugins, for starters.
There are probably more use cases that need to be though of, but expecting
there to be no Cordova code is ridiculous.  Also, part of the reason we're
doing a Mozilla WebView is because it's so radically different from the
Chromium based WebViews we can use it to re-think what is needed.

Honestly, if you think you can do a better job on the API and keep some
backwards compatibility with the current API, spin up a topic branch, but
the 4.0.x branch already contains code that was approved months ago, and
your opposition to it now is ridiculous.  It's like you're trying to derail
the work because of some unknown reason, which wouldn't be a new thing at
all.


>
> >
> >
> > >
> > > On Tue, Sep 30, 2014 at 3:58 PM, Sergey Grebnov (Akvelon) <
> > > v-segreb@microsoft.com> wrote:
> > >
> > > > +1
> > > > It would be also great if there is a way to extend/override some
> > default
> > > > webview functionality as well (not only provide full webview
> > > implementation)
> > > >
> > > > For example, what will be recommended way to extend default
> > > > onReceivedHttpAuthRequest functionality if I want to automatically
> show
> > > > credentials dialog in case of 401 response?
> > > >
> > > >
> > > >
> > >
> >
> https://github.com/apache/cordova-android/blob/master/framework/src/org/apache/cordova/CordovaWebViewClient.java#L116
> > > >
> > > > Thx!
> > > > Sergey
> > > > -----Original Message-----
> > > > From: Joe Bowser [mailto:bowserj@gmail.com]
> > > > Sent: Tuesday, September 30, 2014 10:44 PM
> > > > To: dev
> > > > Subject: Re: [Android] Third Party WebView Reference Implementation
> > > >
> > > > On Tue, Sep 30, 2014 at 10:42 AM, Michal Mocny <mmocny@chromium.org>
> > > > wrote:
> > > >
> > > > > To make sure I understand, this is implementing the system webview
> as
> > > > > a pluggable-webview-via-plugin?
> > > > >
> > > > >
> > > > Yes.  The idea was to use this to figure out our API surface and to
> see
> > > > what's necessary and what's not.  Also, we need a way to test this
> > > without
> > > > having to rely on third party bits from Intel or anyone else.  While
> > it's
> > > > the same implementation, the fact is that it's a slightly different
> > class
> > > > so we could in theory test this and hopefully automate it.
> > > >
> > > >
> > > > > This, is interesting.
> > > > >
> > > > > On Tue, Sep 30, 2014 at 12:47 PM, Joe Bowser <bowserj@gmail.com>
> > > wrote:
> > > > >
> > > > > > Hey
> > > > > >
> > > > > > So, as part of the work for Third Party Webviews, I decided
to
> > write
> > > > > > up a super quick reference implementation by just copying the
> > > > > > AndroidWebView
> > > > > and
> > > > > > making it a plugin.  I haven't fully tested this yet, but it
> should
> > > > > > work
> > > > > as
> > > > > > a third-party WebView.
> > > > > >
> > > > > > The tricky part that I found here is how much of Cordova we
have
> to
> > > > > > keep exposed for Third-Party WebViews to work.
> > > > > >
> > > > > > Anyway, the work is on GitHub with Apache Licences.  Once it
gets
> > > > > massaged
> > > > > > a bit more, it may need a home at Apache.
> > > > > >
> > > > > > https://github.com/infil00p/ThirdPartyWebViewRef
> > > > > >
> > > > > > Feel free to fork it and go through it and put feedback on this
> > > thread.
> > > > > > It's the same code as AndroidWebView in the 4.0.x branch, so
some
> > of
> > > > > > this may be using exposed APIs out of convenience.
> > > > > >
> > > > > > Joe
> > > > > >
> > > > >
> > > >
> > >
> >
>

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