On Mon, Aug 19, 2013 at 4:43 PM, Joe Bowser <[email protected]> wrote:
> 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. > > Thanks for the video link -- I want to check that out. I don't necessarily agree that you need to be creating a custom Activity class if what you really want is a custom WebView (or in my case, a custom WebViewChromeClient). Just as there's no need to modify code to override the Cordova app's start page, it should be quite easy to get the app developer's requested classes through config.xml and instantiate them through reflection, just as plugins are instantiated. I've come up with two ways to have our platform use a custom WebViewChromeClient so far: First was to extend our activity class -- this is simple and works well. (I added a couple of factory methods on CordovaActivity to make it even easier). I only ran into trouble with this when I tried to get cordova-cli to automatically create an app with that new Activity class. To do it cleanly, it looks like I'm going to want to add a flag to cordova-android/bin/create to override the project template, and then modify CLI to pass that flag through from the command line. This is doable, but isn't something that could easily be made accessible to plugin developers. The second way was to do what I proposed above -- allow the classes to be specified in config.xml, defaulting to the org.apache.cordova classes, and let plugins / frameworks / applications use the existing mechanisms to change config.xml at prepare-time. I'm fine with either method; I just think the second one is more accessible to developers. I don't want to have to write code in our build scripts to use CLI and then immediately re-do some of the same work with a different generated Activity class. > > 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. > 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. Ian
