cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ian Clelland <iclell...@chromium.org>
Subject Re: Extending CordovaWebView
Date Thu, 22 Aug 2013 17:43:52 GMT
After thinking about this for a couple of days, and discussing with Andrew
and Michal here, it seem that there are definitely (at least) two different
issues here.


First is that there is no way to use a custom WebView / WebViewClient /
ChromeClient class within the CLI system, without writing custom native
code after your project has been created. This may be acceptable for
individual project authors, but it's a pain for framework authors.

I had suggested two methods to fix this problem: one was to override the
default class names at run-time though config.xml; the other was to
override the platform templates at project creation time.

Thinking some more, it is apparent that overriding templates is strictly
more powerful, although it is only accessible to people who create lots of
apps, and who would therefore have the incentive to create their own
templates. I think I'm going to move forward with this path.


The second issue is how to allow plugins to listen for the (rather large)
set of possible callbacks from these three classes. There are now a couple
of cases where this has been asked: for gesture recognition, and now for
basic auth. I have a couple of ideas as to how to let plugins register for
these, without slowing down the WebView horribly, but I'm going to break
that out into a separate thread for discussion.

Ian

On Wed, Aug 21, 2013 at 6:43 AM, Ally Ogilvie <aogilvie@wizcorp.jp> wrote:

> Currently there is a bug in Android webkit that basic authentication for a
> web resource will only fire once. You can test this by logging all the
> things with this method;
>
> *@Override*
> *public android.webkit.WebResourceResponse
> shouldInterceptRequest(android.webkit.WebView view, java.lang.String url) {
> }*
>
> This is a real ball ache if you have a resources on another server with
> different BA credentials.
>
> If you listen for
>
> *@Override*
> *public void onReceivedHttpAuthRequest(android.webkit.WebView view,
> android.webkit.HttpAuthHandler handler, java.lang.String host,
> java.lang.String realm) { }*
>
> You can set your own credentials with the following example in the above
> method;
>
> String[] credentials = view.getHttpAuthUsernamePassword(host, realm);
> handler.proceed(credentials[0], credentials[1]);
>
> Anyhow, *both the above methods are currently on CordovaWebViewClient*.
> Getting access to these was a b****h.
> Exposing these to the Plugin would be totally badass.
> I can submit something for this but it's pretty big.
> Would like to know what the consensus is on this first. People?
>
>
>
> On Wed, Aug 21, 2013 at 3:48 AM, Ally Ogilvie <aogilvie@wizcorp.jp> wrote:
>
> > I think there is a requirement to offer this at the plugin level at
> > least. Basic authentication is an obvious one.
> > Try load an image with a source where the URL is basic authenticated.
> > Good luck :)
> >
> > Some additional overrides are necessary.
> >
> > Sent from my Windows Phone From: jbondc@openmv.com
> > Sent: 20/08/2013 23:12
> > To: dev@cordova.apache.org
> > Subject: RE: Extending CordovaWebView
> > On Mon Aug 19 05:21 PM, Ian Clelland wrote:
> > > On Mon, Aug 19, 2013 at 4:43 PM, Joe Bowser <bowserj@gmail.com> wrote:
> > >
> > > >
> > > > I don't think that we should replace Java code with XML.  This is a
> > > > lot different than just reading constants from an XML file.  If
> you're
> > > > going to mess around with the webview, you should be forced to
> > > > understand what you're doing.  It's already bad enough that hardly
> > > > anybody reads the plugin code before they cram it into their
> projects.
> > > >
> > >
> > > It's not replacing Java code with XML -- if anything, it's *more* Java
> > > code :).
> > > Just using reflection to instantiate the correct classes,
> > > exactly like plugin
> > > installation / invocation.
> >
> > I'm somewhat for the idea but it seems too early to start thinking how
> > this would be implemented.
> > Maybe it turns out there's only 2-5 plugins that would need this.
> >
> > One thing that could help is an <experimental></experimental> section
> > in plugin.xml to try different approaches.
> > That part could break at any time, if there's eventually consensus on
> > the feature and syntax, it gets merged in plugin.xml
> >
>
>
>
> --
> <http://www.wizcorp.jp/>Ally Ogilvie
> Lead Developer - MobDev. | Wizcorp Inc. <http://www.wizcorp.jp/>
> ------------------------------
> TECH . GAMING . OPEN-SOURCE WIZARDS+ 81 (0)3-4550-1448 |
> Website<http://www.wizcorp.jp/>
>  | Twitter <https://twitter.com/Wizcorp> |
> Facebook<http://www.facebook.com/Wizcorp>
>  | LinkedIn <http://www.linkedin.com/company/wizcorp>
>

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