cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ian Clelland <>
Subject Extending CordovaWebView
Date Mon, 19 Aug 2013 18:40:57 GMT
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

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

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.

Plugins could specify a new class to use in plugin.xml, or a framework like
Mobile Chrome Apps could manipulate config.xml at project creation time.
Individual application developers, of course, can change their config.xml
files by hand as needed. This should give all parties the flexibility to
override whatever behaviour is needed.

One obvious shortcoming of this is that multiple plugins may not work well
together under this regime. Two plugins which each redefine
CordovaWebViewClient would probably both affect config.xml, and just like
with the <content> tag, one of them would consistently 'win' at runtime.
I'm working on a solution to that problem, but for right now, my answer if
that happens would be to move the responsibility up a level: If an
application developer installs two conflicting plugins, then they can
(relatively) easily write a class which combines the code from the two, and
use that for their application.

If anyone wants, I'll post my changes to cordova-android up on a branch for
review, byt they're really quite straightforward. I'm interested in any
feedback on the idea itself.'



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