cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Bowser <>
Subject Re: Extending CordovaWebView
Date Mon, 19 Aug 2013 20:43:12 GMT
On Mon, Aug 19, 2013 at 11:40 AM, Ian Clelland <> wrote:
> For Mobile Chrome Apps, we have a need to subclass the CordovaChromeClient
> class used by our applications.  There's not currently a way to do that in
> the CLI world
> Also, in [this thread][1], there has been some discussion of plumbing
> additional WebView callback methods to plugins. I think that it's a
> perfectly reasonable request, and whether or not the answer for these
> particular methods involves changing the base CordovaWebView class, there
> are likely to be more and more such requests -- there are hundreds of such
> methods that any given plugin *could* want to intercept.
> I don't think that we should be adding hooks for every conceivable callback
> method; that's a lot of bloat, and it doesn't actually help for some use
> cases.
> Instead, I'd like to propose making the WebView (and related client
> objects) class configurable, so that applications, frameworks, and possibly
> plugins can easily subclass them without having to override the default
> template-generated Activity file (which is supposed to be a build artifact
> anyway)

I have always disagreed with the whole "Native Code is a Build
Artifact" philosophy of our tools, however I'll admit that for 90% of
the time, that's the case.  That being said, I recommend that people
read Lindsay Simon's presentation on developing a PhoneGap application
on Android and see how people make REALLY GOOD applications, leverage
HTML and JS and don't flee from Java
( The
fact is that if you're starting to change things like touch events on
the WebView yourself, you should probably be implementing a custom
activity as well.  Just because we produce a bunch of boiler code, it
doesn't mean that users shouldn't be able to modify the Java code if
they are doing crazy things like this.

> This means that CordovaActivity would get the names of those classes from
> config.xml, just like it gets the start page from the <content> tag, and
> use those names when instantiating the webview. Of course, for backwards
> compatibility, they would default to org.apache.cordova.CordovaWebView,
> CordovaWebViewClient and CordovaChromeClient.

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.

View raw message