On Wed, Oct 1, 2014 at 7:24 AM, Andrew Grieve <[email protected]> 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. 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. > > On Tue, Sep 30, 2014 at 3:58 PM, Sergey Grebnov (Akvelon) < > [email protected]> 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:[email protected]] > > 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 <[email protected]> > > 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 <[email protected]> > 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 > > > > > > > > > >
