cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ian Clelland <iclell...@chromium.org>
Subject Re: Extending CordovaWebView
Date Mon, 19 Aug 2013 21:21:43 GMT
On Mon, Aug 19, 2013 at 4:43 PM, Joe Bowser <bowserj@gmail.com> wrote:

> On Mon, Aug 19, 2013 at 11:40 AM, Ian Clelland <iclelland@chromium.org>
> 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

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