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) 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.' Ian [1] http://callback.markmail.org/thread/lrfiy5j7o5tv5ma5
