Re: Extending CordovaWebView

[Lindsey Simon <ls...@commoner.com>]

I was wondering how this is progressing.. (maybe there's already a
mechanism for this via config.xml?)
I ask because, in the CLI world, I'm not sure how to update webview
settings for android, in particular because I'd like to make the changes
mentioned here:
http://tmkmobile.wordpress.com/2012/03/04/html5-offline-solution/
super.appView.getSettings().setDomStorageEnabled(true);
super.appView.getSettings().setAppCacheMaxSize(1024*1024*8);
super.appView.getSettings().setAppCachePath("/data/data/com.yourdomain/cache");
super.appView.getSettings().setAllowFileAccess(true);
super.appView.getSettings().setAppCacheEnabled(true);
super.appView.getSettings().setCacheMode(WebSettings.LOAD_DEFAULT);


On Tue, Aug 27, 2013 at 7:45 AM, Ian Clelland <ic...@chromium.org>wrote:

> 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 <ao...@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 <ao...@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
> >
>

Re: Extending CordovaWebView

[Andrew Grieve <ag...@chromium.org>]

Ian ended up adding a setting to .cordova/config.json that allows you to
point to a custom template for "platform add" to use. Probably not
applicable to your use-case.

I'd say you could go one of two routes for this change:
1. Just make the changes right in your Foo.java (extends CordovaActivity)
file. This file is never touched by the tools.
2. Write a plugin that sets these settings, and have that plugin load on
start-up via <feature ...><param name="onload" value="true"/>


On Fri, Dec 20, 2013 at 4:18 PM, Lindsey Simon <ls...@commoner.com> wrote:

> I was wondering how this is progressing.. (maybe there's already a
> mechanism for this via config.xml?)
> I ask because, in the CLI world, I'm not sure how to update webview
> settings for android, in particular because I'd like to make the changes
> mentioned here:
> http://tmkmobile.wordpress.com/2012/03/04/html5-offline-solution/
> super.appView.getSettings().setDomStorageEnabled(true);
> super.appView.getSettings().setAppCacheMaxSize(1024*1024*8);
>
> super.appView.getSettings().setAppCachePath("/data/data/com.yourdomain/cache");
> super.appView.getSettings().setAllowFileAccess(true);
> super.appView.getSettings().setAppCacheEnabled(true);
> super.appView.getSettings().setCacheMode(WebSettings.LOAD_DEFAULT);
>
>
> On Tue, Aug 27, 2013 at 7:45 AM, Ian Clelland <iclelland@chromium.org
> >wrote:
>
> > 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 <ao...@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 <ao...@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
> > >
> >
>