On Mon, Aug 19, 2013 at 11:40 AM, Ian Clelland <[email protected]> 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 (http://www.oscon.com/oscon2013/public/schedule/detail/29114). 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.
