Mailing-List: contact dev-help@cordova.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cordova.apache.org
Received-SPF: pass (nike.apache.org: domain of iclelland@google.com designates
 209.85.214.173 as permitted sender)
MIME-Version: 1.0
Sender: iclelland@google.com
In-Reply-To: <65843418706200230@unknownmsgid>
References: <65843418706200230@unknownmsgid>
From: Ian Clelland <iclelland@chromium.org>
Date: Tue, 27 Aug 2013 10:45:05 -0400
Message-ID: 
 <CAK_TSXJyA-aHsQw_yMqNC3e=Lk38gNEzs5fNV=4tgktmr9DHVg@mail.gmail.com>
Subject: Re: Extending CordovaWebView
To: "dev@cordova.apache.org" <dev@cordova.apache.org>
Content-Type: multipart/alternative; boundary=047d7b33d5a054dab404e4eeec3d

--047d7b33d5a054dab404e4eeec3d
Content-Type: text/plain; charset=UTF-8

Issues CB-4671 and CB-4678 added to JIRA for this.

If I have time this week, I'll take a stab at implementing them.


On Fri, Aug 23, 2013 at 12:30 PM, Ally Ogilvie <aogilvie@wizcorp.jp> wrote:

> Hell. Yes. Plus all the things you just wrote +1
>
> Sharing is caring... Is why i want accessibility in plugins for maximum
> awesomeness.
>
> Sent from my Windows Phone From: Ian Clelland
> Sent: 23/08/2013 23:41
> To: dev@cordova.apache.org
> Subject: Re: Extending CordovaWebView
> 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
>

--047d7b33d5a054dab404e4eeec3d--