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 Fri, 23 Aug 2013 14:40:18 GMT
On Thu, Aug 22, 2013 at 8:43 PM, Ally Ogilvie <aogilvie@wizcorp.jp> wrote:

> > First is that there is no way to use a custom WebView / WebViewClient /
> > ChromeClient class within the CLI system, without writing custom native
> > code after your project has been created.
>
> Not sure about the CLI system, don't really use it. Call me old school but
> I love my jars 'n frameworks. There is of course another reason for this;
> Cordova is very much a framework for me, NOT a platform. I think it's
> crucial to remember there are many reasons to use Cordova in a project, it
> can often be just as a means to get a little extra accessibility and
> browser standardisation out of the WebView. The rest of the app could be
> 80% native with heaps of other SDKs...
>

That is absolutely a valid use of Cordova, and underscores the point that
the tools which underlie CLI should be even more stable than CLI itself.
(Which I think is true right now)

If you're using Cordova in that way, then most of this discussion wouldn't
even apply -- your start-of-project flow can just be
"cordova-android/bin/create newproject com.example.newproject", and then
you can start editing (or just throw away) the default Activity class.
Nothing here is going to get in the way of that.



>
> >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
>
> Ian, I know you are using CLI, but IF you were not, you would subclass
> CordovaChromeClient on your application's main Activity?? I see no sensible
> way to do it on a Plugin without going thread crazy... I can separate a
> thread if you want to keep this CLI related, but I feel the plugin
> developer use case should be considered in this thread too.
>

The only reason I can imagine for me not to use CLI would be if I was
creating a single-platform application, for which I knew that I was going
to be making a lot of native code modifications. In that case, I would
absolutely introduce my own subclass of CordovaChromeClient, and import it
in my main Activity, and override init() to create the right objects.

But that only works for my application; it doesn't give me anything that I
can share with other developers without also instructing them to modify
their code in the same way.

There's no way right now to encapsulate this sort of change in a plugin.
The CordovaWebView/Client/ChromeClient are necessarily singletons, and it's
probably not a good idea to allow plugins to arbitrarily replace them. We
could conceivably come up with a new sort of plugin that can do it -- and
you could only install one such plugin per project -- but people could also
just distribute custom app templates which do pretty much the same thing.


>
> I'm 100% hopeful that at a minimum more methods (WebView and WebViewCient)
> can be exposed to the Plugins.
>

For individual methods, right now lets just name them specifically, and we
can add delegation to the plugins for them. Later, I think we can move to a
generic registration / notification architecture, once we have a good
design for that.

I've heard calls for:
 - disableTouchEvents
 - registerGestureHandler
 - onReceivedHttpAuthRequest
 - getHttpAuthUsernamePassword

We can create some issues for those, and get them implemented.

Ian

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