RE: Proposal: hooks support for plugins

[Jonathan Bond-Caron]

On Mon Apr 21 03:39 PM, Sergey Grebnov (Akvelon) wrote:
> module.exports = function(platform, projectDir, pluginDir, cmdLine) {
> console.log('hook.js: ' + platform);
> console.log('hook.js: ' + projectDir);
> console.log('hook.js: ' + pluginDir);
> console.log('hook.js: ' + cmdLine);
> 

Personnaly prefer:

> module.exports = function(hookApi) {
> console.log('hook.js: ' + hookApi.platform);
> console.log('hook.js: ' + hookApi.projectDir);
> console.log('hook.js: ' + hookApi.pluginDir);
> console.log('hook.js: ' + hookApi.cmdLine);}

Make it easier to pass other stuff in the future & using a sandoxed hookApi 
object.

RE: Proposal: hooks support for plugins

[Jonathan Bond-Caron]

On Fri Apr 18 11:35 AM, Sergey Grebnov (Akvelon) wrote:
> Sound like most of us prefer module.export.  Cool, will update the code today
> and let you know once this is done.
> 
> Since we will be moving to cordova-lib the next action item here could be
> creating uniform hooks with shared code for both application level and plugin
> level hooks. Thoughts?
> 

+1, great for moving this forward. Makes sense as a module in cordova-lib. 

Would be nice to support inline  tags.

Agree with using same mechanism for the cli hooks.

RE: Sharing code between plugman and cordova-cli

[Jonathan Bond-Caron]

On Tue Apr 15 09:36 AM, Andrew Grieve wrote:
> I think everyone is on board with the idea that modules should be used to 
> enable
> sharing code, and for code organization.
> 
> Two problems that are happening in practice:
> - Multiple pull requests (plugman and CLI) to make a change
> - Code duplication between the repositories
> 

+1, from a new contributor's perspective, learning about git & coordinating 
pull requests to 2+ repos was quite challenging. Probably equally challenging 
to review :) 

> - Only one tool for devs to install (aptly named "cordova")
>- "cordova --help" as one entry-point to what's available

Like this, with cordova-lib or cordova-common being a reasonable transition to 
help clarify how or if plugman should be merged. 

RE: [cordova-js] do we need , ?

[Jonathan Bond-Caron]

On Thu Apr 10 01:35 PM, Michal Mocny wrote:
> 
> List of hangouts scheduled:
> https://wiki.apache.org/cordova/Google%20Hangout%20Discussion%20Notes
> Agenda for this next one: https://wiki.apache.org/cordova/Agenda20140415
> 

Awesome, I'll join in

Cheers,
Jon

RE: [cordova-js] do we need , ?

[Jonathan Bond-Caron]

On Wed Apr 9 08:40 PM, Brian LeRoux wrote:
> 
> The cons are wrong. You can import plugins and indeed you can test plugins.
> The statement that we shouldn't need to compile/transpile is not correct if we
> want to evolve things. Its the only path we have that will keep things 
> backwards
> compatible. (That we could determine.) 

I put up an example here:
https://github.com/gdesolutions/ja-lib/tree/master/tests/plugins/file.encrypt

The cons were against the current plugin.xml & , 
To be clear, it's a pro for using something like browserify.

If part of the net benefit is we can have a story like:
cordova create plugin file.encrypt
https://github.com/gdesolutions/ja-lib/tree/master/tests/plugins/file.encrypt/package.json

Extend existing plugin:
https://github.com/gdesolutions/ja-lib/tree/master/tests/plugins/file.encrypt/LocalFileSystem-es6.js

cordova plugin test <--- this (runs in some bleeding edge browser)

That's a big win / net benefit for being more opiniated about the module format.

The browserify node.js story looks like:
https://github.com/gdesolutions/ja-lib/tree/master/tests/plugins/file.encrypt/LocalFileSystem.js

But trying to bring the entire node.js api *into* the browser is a big hack, 
turning an apple into an orange.

RE: [cordova-js] do we need , ?

[Jonathan Bond-Caron]

On Tue Apr 8 03:50 PM, Andrew Grieve wrote:
> 
> The question of whether we *need* them is not a good way to phrase it I think.
> Rather:
> Pros? 

- Cordova doesn't pick a style of writing modules/plugins
- More control over how plugin loading works

Prefer this approach for now, might be a better way to do this eventually:
https://plus.google.com/+PaulIrish/posts/cHLhcSfJyJo

Good points by Alex Young, James Burke

> Cons? 

- No way to require() or import() other plugins, e.g. extend a plugin
- Difficult to "test" cordova plugins 
- Shouldn't need to compile/transform/transpile a plugin to test it

> Worth changing at this point?

Not a fan of any 'bundling' tool with so many dependencies:
https://github.com/substack/node-browserify/blob/master/package.json
https://github.com/webpack/webpack/blob/master/package.json

The ES6 web modules situation is evolving, but still messy:
https://github.com/addyosmani/es6-tools

Seems better to experiment more

RE: About cordova js

[Jonathan Bond-Caron]

On Tue Apr 1 07:27 AM, Anis KADRI wrote:
> I've been working on an alternative build system for cordova-js over the last 
> little
> while and I finally have something to share.
> 

Personally like this direction

> 
> Some random thoughts for the future:
> - clobbers/merges/runs should be useless. plugins should clobber/merge if they
> want/need to. Each plugin can just be written as a commonJS module.
> - pluginloader/modulemapper will no longer used.
> - We could actually leverage NPM dependencies for javascript modules.
> Native code will still have to be resolved but this could be a big win for 
> js-only
> platforms.
> - Since we decided to ditch everything for node, I think browserify is a step 
> in the
> right direction.

Confused about this part, npm modules run on the server (access to the entire 
filesystem).
Transforming or transpiling npm modules into web things is a hack.

There's already standard web modules in the works:
https://github.com/dherman/web-modules

Cordova plugins are more like these 'web modules'. Which is why bower makes 
more sense than npm as a registry.

Npm & cordova modules have the same *programming language* (javascript), not to 
be confused with same *execution environment*.

RE: cordova launcher icon support https://github.com/apache/cordova-cli/pull/126

[Jonathan Bond-Caron]

On Thu Apr 3 09:20 AM, Bryan Higgins wrote:
> My point is only that we should be consistent. If the platform element is 
> used for
> preference, then why introduce an attribute which does the same thing for 
> icon?
> 
> Also, I've seen platform=, cdv:platform= and gap:platform= within the pull
> requests.
> 

Cordova is basically stuck in a Design by committee loop

On the positive side, there's many solutions :)

RE: cordova launcher icon support https://github.com/apache/cordova-cli/pull/126

[Jonathan Bond-Caron]

On Thu Apr 3 05:06 AM, Axel Nennker wrote:
> It is a shame that CB-2606 is unresolved this long. We should have something
> rolled out soon.
> 

+1, thoughts on splashscreens or other images?

 

RE: Consolidating the Distribution of Platforms & Plugins

[Jonathan Bond-Caron]

On Sat Mar 29 03:11 PM, Brian LeRoux wrote:
> I think its a great idea. The platforms have a standard interface [1] for 
> which the
> higher level CLI Node module depends. We could remove our logic for
> versioning/caching and leave that to npm. We distribute via npm already for 
> the
> CLI so this is just a natural extension. We'd win less code, and a cleaner
> implementing focused on the CLI needs not dependency management (that npm
> does better).
> 

Sounds good to me, platforms make sense on npm, expected to run in node.js 
environment

> Hosting our Plugins on the vanilla npm registry won't work. We investigated 
> that
> path. (Though I welcome anyone here to do their own research.) Ultimately, we
> have a different set of needs on installation, and and in the act of 
> packaging.
> We'd win distribution, but we have that already, so we'd be solving nothing.
> 

Agree with all of Andrew's points, recently looked into 'bower':
http://tech.pro/tutorial/1190/package-managers-an-introductory-guide-for-the-uninitiated-front-end-developer#front_end_developers

Dependencies are flat which resembles a bit more cordova:

  - npm things (~ node.js javascript / v8 runtime) 
  - cordova things (native code + javascript, multiple webviews)
  - bower things (javascript, multiple browsers)

Bower things are compatible with cordova, might be worth looking into.

RE: [GitHub] cordova-cli pull request: CB-6322 Simplify platforms/platform code...

[Jonathan Bond-Caron]

On Fri Mar 28 03:16 PM, Jesse wrote:
> 'process.platform' in node returns win32 for windows ( 32+64 ) 'process.arch'
> returns x64 if it is 64bit
> 
> 

Interesting didn't know.

In case anyone is curious about this, refers to v8's 'win32' platform / win32 
api
https://github.com/joyent/node/blob/0c5a0ecc7c8b203aa34a43f0fb8f3bf81cce7f41/deps/v8/src/platform-win32.cc

Used here:
https://github.com/joyent/node/blob/master/lib/os.js#L24

There's no win64 'platform' support in v8

RE: Consolidating the Distribution of Platforms & Plugins

[Jonathan Bond-Caron]

gt; > > 
> > > > wrote:
> > > > >
> > > > > > I don't see how we can rely on npm's dependency system (or npm
> > > install)
> > > > > for
> > > > > > Cordova because npm dependencies consist of a tree of isolated
> > > > > > node_modules/ whereas cordova has to share code amongst
> > > > > > multiple
> > > > plugins
> > > > > > (different build system than npm/node). We could use `npm
> > > > > > install`
> > > for
> > > > > > auto-fetching but we might fetch the same plugin multiple
> > > > > > times if
> > > > other
> > > > > > plugins depend on it. The meat of dependency management is not
> > > > > > in
> > the
> > > > > > fetching part.
> > > > > >
> > > > > > We actually looked into leveraging npm for everything but it
> > > > > > turned
> > > out
> > > > > to
> > > > > > be not possible. Cordova projects are just not exactly like
> > > > > > node
> > > > > projects.
> > > > > >
> > > > > > Also from a user/developer perspective it's a lot nicer to
> > > > > > have one
> > > > place
> > > > > > to look for cordova plugins rather than ~65 000 npm packages
> > > > > > of
> > which
> > > > > most
> > > > > > are not even Cordova related. Platforms don't matter because
> > > > > > users/developers are not supposed to be aware of their existence.
> > > > > >
> > > > > > my 0.02
> > > > > >
> > > > > > -a
> > > > > >
> > > > > >
> > > > > > On Sat, Mar 15, 2014 at 3:54 PM, Carlos Santana <
> > > csantan...@gmail.com
> > > > > > >wrote:
> > > > > >
> > > > > > > Jonathan
> > > > > > >Today we don't support that scenario with cordova cli, if
> > > > > > > a
> > > plugin
> > > > > > > supports multiple platforms you can't block "cordova plugin add"
> > > from
> > > > > > > installing to all platforms that it supports.
> > > > > > > Maybe a new enhancement request?
> > > > > > >
> > > > > > > My intention with having the dependencies info was solely to
> > > > > > > get
> > > the
> > > > > all
> > > > > > > the dependency files download via npm, either via user
> > > > > > > running
> > "npm
> > > > > > > install" or cordova using user's global npm to get the files
> > > > > > > down
> > > to
> > > > > the
> > > > > > > system.
> > > > > > > It was not the intention of "dependencies" to drive the
> > composition
> > > > of
> > > > > > the
> > > > > > > App. it can be use but I think more control using like an
> > > > > > > new
> > > > property
> > > > > > > "cordova" in package.json, or pacakge.json may not have this
> > > > > > > info
> > > and
> > > > > > just
> > > > > > > deal with dowloading the correct versions of platform and
> > plugins,
> > > to
> > > > > > then
> > > > > > > be use by "cordova lib" to do it's thing.
> > > > > > > This also gives flexibility to drive cordova how ever  the
> > > > > > > user
> > > wants
> > > > > > even
> > > > > > > with npm "scripts" lifecycles with a "postinstall"
> > > > > > >
> > > > > > > Yes I agree the devils is in the details, and a lot of space
> > > > > > > for exploration going forward.
> > > > > > >
> > > > > > > --Carlos
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On Sat, Mar 15, 2014 at 9:11 AM, Jonathan Bond-Caron <
> > > > > > > jbo...@gdesolutions.com> wrote:
> > > > > > >
> > > > > > > > On Fri Mar 14 11:36 PM, Carlos Santana wrote:
> > > > > > > > > I have being thinking on this sort of problem also.
> > > > > > > > >
> > > > > > > > > I think using npm to store none node code is perfectly
> > > > > > > > > fine
> > use
> > > > > case.
> > > > > > > > >
> > > > > > > > > I vote to leverage npm as the building block and then
> > > > > > > > > build
> > > > cordova
> > > > > > > > functions on
> > > > > > > > > top of it.
> > > > > > > > >
> > > > > > > >
> > > > > > > > +1 where possible like caching
> > > > > > > >
> > > > > > > > >
> > > > > > > > > "dependencies": {
> > > > > > > > >"org.apache.cordova.platform.ios": ">=3.4.0",
> > > > > > > > >"org.cordova.platform.android": ">=3.3.0",
> > > > > > > > >"org.apache.cordova.device": "~0.2.8",
> > > > > > > > >"cordova-cli": "~3.4.0"
> > > > > > > > > },
> > > > > > > >
> > > > > > > > That's a bit of an oversimplification, you may not want
> > > > > > > > the
> > same
> > > > > plugin
> > > > > > > on
> > > > > > > > android & ios.
> > > > > > > >
> > > > > > > > -1 on dependencies through npm, +1 with Braden for cordova
> > > > > > > > lib
> > > that
> > > > > > > > handles the dependency fetching.
> > > > > > > >
> > > > > > > > Devil's in the details so +1 for experimenting though
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > Carlos Santana
> > > > > > > 
> > > > > > >
> > > > > >
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Carlos Santana
> > > > 
> > > >
> > >
> >

RE: Platform specific preferences

[Jonathan Bond-Caron]

On Tue Mar 18 04:20 PM, Andrew Grieve wrote:
> No idea :P. Stumbled upon it when I was doing a recent CLI refactoring.
> 
> 

+1 for the change but we'd have to drop the widget namespace, no?
https://github.com/apache/cordova-cli/commit/45e80ac1b2c73a18155e74ac286067a4299742d8#diff-6e0c580ec9d220fc4b32a0ffd9b41595R151


Even tests for it:
https://github.com/apache/cordova-cli/commit/45e80ac1b2c73a18155e74ac286067a4299742d8#diff-3a9ac8021b53843b4e1be5b27e6d7188R241

IMHO, "proper" way to do this would be ~




And after removing widget spec:


   


Well anyways, assuming splashcreen is a preference instead of a required image.

But heck looks like inconsistency is winning,
J
 

RE: Consolidating the Distribution of Platforms & Plugins

[Jonathan Bond-Caron]

On Fri Mar 14 11:36 PM, Carlos Santana wrote:
> I have being thinking on this sort of problem also.
> 
> I think using npm to store none node code is perfectly fine use case.
> 
> I vote to leverage npm as the building block and then build cordova functions 
> on
> top of it.
> 

+1 where possible like caching

> 
> "dependencies": {
>"org.apache.cordova.platform.ios": ">=3.4.0",
>"org.cordova.platform.android": ">=3.3.0",
>"org.apache.cordova.device": "~0.2.8",
>"cordova-cli": "~3.4.0"
> },

That's a bit of an oversimplification, you may not want the same plugin on 
android & ios. 

-1 on dependencies through npm, +1 with Braden for cordova lib that handles the 
dependency fetching.

Devil's in the details so +1 for experimenting though

RE: Releasing Platforms Independently

[Jonathan Bond-Caron]

On Thu Mar 13 11:38 AM, Andrew Grieve wrote:
> I think it would be beneficial if we could release updates to platforms
> independent from others. Why?
> - Far easier to do one-off platform releases (e.g. quick turn-around on a 
> security
> update, quick turn around on iOS is broken on the latest Xcode)
> - Platforms can release on their own schedule (big new features will get 
> released
> sooner)
> 

+1

> 
> cordova-js:
>  - Platforms will have cordova-js cut at different times.
>- I don't think this is a good or a bad thing.
>  - JS versioning stamped at the top of the file:
>- Change to have both platform version as well as JS version available at
> runtime.
>- JS version will just be a "git describe"
> 

I've been thinking we could go a step further and break out 'platforms' into 
two parts:
- platform engine (build, run, emulate tooling) 
- platform runtime (webview, cordova-js, the stuff needed by web app)

 tags in plugin.xml are really only about checking the tooling at 
install time, from what I understand

RE: plugman create plugin on Windows issues

[Jonathan Bond-Caron]

On Fri Mar 14 10:56 AM, Lisa Seacat DeLuca wrote:
> Bas, good catch.   
> 
> Still seeing the same error though when I use a : instead of ; 
> 
> C:\workspaces\lisa\test2>plugman install --platform android --project 
> C:\workspaces\lisa\test2\www --plugin C:\workspaces\lisa\TestPlugin 
> Installing com.ibm.cordova.plugin.test (android) 
> ENOENT, no such file or directory 
> 'C:\workspaces\lisa\test2\www\AndroidManifest.xml' 
> 
> Sergey's work around of using the CLI instead of plugman works for now. 
> 

C:\workspaces\lisa\test2>plugman install --platform android --project 
.\platforms\android --plugin C:\workspaces\lisa\TestPlugin
C:\workspaces\lisa\test2>plugman uninstall --platform android --project 
.\platforms\android --plugin C:\workspaces\lisa\TestPlugin

Unfortunately not a bug, just not intuitive at all :/

Plugman expects the 'native' project path (.\platforms\android) & installs 
plugins in .\platforms\android\cordova\plugins
Cli installs plugins in .\plugins

In general, mixing cli & plugman isn't a good, there're incompatible since they 
install plugins in different locations.

RE: cordova templates?

[Jonathan Bond-Caron]

On Fri Mar 14 10:02 AM, Braden Shepherdson wrote:
> To be clear, you're suggesting that we have templates in the form of
> plugins? I'm
> not sure that's what we really want. At least, if we
> install them like regular plugins
> then there are several values that
> need to be changed, including the directory
> name.

They would ~ fetchPluginAndDeps() the same way as plugins. But at install() 
time, we just run install scripts + install() their plugin dependencies.

Ideally the install script could setup config.xml preferences & do some magic.

- Option (a) is we know it's a template because it's in the template.* 
namespace.
- Option (b) is to call it template.xml instead of plugin.xml

This requires using a plugman.fetchPluginAndDeps() that downloads only into a 
temp directory.

Right now plugman.fetch() is fetchAndCopyToPluginDir()

> 
> Perhaps cordova template add org.apache.cordova.template.hello-world
> my.new.plugin.id and it does the appropriate renaming at install time?
> 

It's really a one-time operation kind of thing, a way to install plugin 
dependencies + preferences in 1 swoop.

The plugin install() logic would need to be tweaked to know it's a template.

> No comment on template.* namespace vs. foo.bar.template.baz or whatever.
> If
> we're going to allow templates as pseudo-plugins, why not allow
> anyone to
> publish a template? Users may have good ideas for templates
> that would be
> useful to themselves, and maybe to others as well.
> 

Yep seems like a win to me.

cordova templates?

[Jonathan Bond-Caron]

Thoughts supporting starter templates like plugins?

 e.g. Something like this:

cordova template add apache.hello.world  (plugin.xml)
cordova template add apache.hello.world.native.dude  (plugin.xml)

Internally it's a:
cordova plugin add template.apache.hello.world

Reserve template.* namespace?

Bonus is there's an indication of which starter templates people are using.

There's some minor implementation details like:
cordova template add apache.hello.world
cordova plugins ls
[template.apache.hello.world]
[org.apache.cordova.statusbar]
[org.apache.cordova.console]

What we'd probably want is:
cordova plugins ls
[org.apache.cordova.statusbar]
[org.apache.cordova.console]

Templates can only install, can't update.
Users publishing a template - yes / no?

> -Original Message-
> From: brian.ler...@gmail.com [mailto:brian.ler...@gmail.com] On Behalf Of
> Brian LeRoux
> Sent: March 11, 2014 1:05 PM
> To: dev@cordova.apache.org
> Subject: Re: [cordova-plugins/statusbar] Publishing as core
> 
> I like this idea. Achieves all concerns. (Separation thereof, and onboarding 
> ease.)
> 
> 
> On Tue, Mar 11, 2014 at 9:04 AM, Carlos Santana
> wrote:
> 
> > +1 Keep it as a plugin not embed into platform repo
> >
> > default plugins ?
> >
> > what about binding a set of default plugins with our www template app
> > (the template app specified what plugins are required)
> >
> > meaning associate a set of plugins with a template www app, and not
> > associate with platform or cli
> >
> >
> >
> >
> >
> > On Tue, Mar 11, 2014 at 10:37 AM, Andrew Grieve  > >wrote:
> >
> > > Plugins allow us to share JS. Rolling statusbar into platforms means
> > > different JS for all platforms, and make it easier for the APIs to
> > diverge.
> > >
> > > Plugins allow us to share docs, and to have the docs live with the code.
> > > APIs like Android's "app" plugin don't have very good docs (or maybe
> > > they are just undiscoverable, or maybe I've just missed where they
> > > are). But having consistency with docs is a big win I think, so
> > > having statusbar
> > as a
> > > plugin means devs can go to its plugin page to find its docs.
> > >
> > > I think just having default plugins would achieve the "everyone will
> > > probably want it" concern. But having it show up in "cordova plugin ls"
> > > will help devs discover that it's there and that they should
> > > probably use it.
> > >
> > >
> > > On Tue, Mar 11, 2014 at 8:49 AM, Jonathan Bond-Caron <
> > > jbo...@gdesolutions.com> wrote:
> > >
> > > > On Mon Mar 10 04:07 PM, Jesse wrote:
> > > > > More on the concept of rolling into a platform ...
> > > > > My distinction is that there are some things that every platform
> > should
> > > > consider a
> > > > > baseline of browser functionality, and if the OS SDKs do not
> > > > > provide
> > it
> > > > out of the
> > > > > box, then we should. Some examples of this :
> > > > >
> > > > > 1. Local XHR, Windows Phone does not support xhr when trying to
> > access
> > > a
> > > > file://
> > > > > url, I could have made this a plugin that would only be used on
> > > > > WP,
> > but
> > > > I think
> > > > > this functionality should be intrinsic, so now it is.
> > > >
> > > > +1
> > > >
> > > > > 2. console.log: if you create a brand new iOS cordova project,
> > > > > the
> > > > hello-world app
> > > > > gives you some boilerplate code to get started.  One thing that
> > > > > new
> > > > users may
> > > > > notice is the use of console.log in index.js, however, they will
> > never
> > > > see the
> > > > > output.  Hooking conosle.log output to go to the command-line
> > > > > output
> > of
> > > > a run
> > > > > command, or the output window of visual studio, or xcode is the
> > minimum
> > > > > functionality, and I personally think it should be built in.
> > > > > This is
> > > > probably best
> > > > > discussed in a new thread, as I know Michal has a different
> > > > > opinion,
> > > > because of
> > > > > some weinre edge case, but this is meant to serve more as an example.
> > > > >
> > > >
> > > > Yep agree, distinction here is there's ~ "web dev" flow and
> > > > "native
> > dev"
> > > > flow (using an IDE)
> > > >
> > > > Both of those should be core somehow
> > > >
> > > >
> > >
> >
> >
> >
> > --
> > Carlos Santana
> > 
> >

RE: [cordova-plugins/statusbar] Publishing as core

[Jonathan Bond-Caron]

On Mon Mar 10 04:07 PM, Jesse wrote:
> More on the concept of rolling into a platform ...
> My distinction is that there are some things that every platform should 
> consider a
> baseline of browser functionality, and if the OS SDKs do not provide it out 
> of the
> box, then we should. Some examples of this :
> 
> 1. Local XHR, Windows Phone does not support xhr when trying to access a 
> file://
> url, I could have made this a plugin that would only be used on WP, but I 
> think
> this functionality should be intrinsic, so now it is.

+1

> 2. console.log: if you create a brand new iOS cordova project, the 
> hello-world app
> gives you some boilerplate code to get started.  One thing that new users may
> notice is the use of console.log in index.js, however, they will never see the
> output.  Hooking conosle.log output to go to the command-line output of a run
> command, or the output window of visual studio, or xcode is the minimum
> functionality, and I personally think it should be built in. This is probably 
> best
> discussed in a new thread, as I know Michal has a different opinion, because 
> of
> some weinre edge case, but this is meant to serve more as an example.
> 

Yep agree, distinction here is there's ~ "web dev" flow and "native dev" flow 
(using an IDE)

Both of those should be core somehow

RE: [cordova-plugins/statusbar] Publishing as core

[Jonathan Bond-Caron]

> Import 'plaforms/android' into Eclipse:
> https://onedrive.live.com/?gologin=1&mkt=en-
> US#cid=295047487FC4F731&id=295047487FC4F731%215602&v=3
> 
> Broken... but "cordova run" works... Is using eclipse still a 'core' thing?
> It's a "still want to use an IDE" thing. My preference is a cordova that 
> embraces
> diversity.
> 

Related:
https://issues.apache.org/jira/browse/CB-3445

My impression is Cordova gets used in different ways by many, championing 
certain "flows" could be a path towards stability & better ecosystem.

I think what I'm trying to say is if there's a 'champion' committer for the IDE 
flow and he or community needs plugins (a,b,c), then that flow & the plugins 
(a,b,c) should be considered core.

Plugin dependencies rolled into platforms doesn't seem like the right direction.

RE: [cordova-plugins/statusbar] Publishing as core

[Jonathan Bond-Caron]

On Mon Mar 10 02:52 PM, Brian LeRoux wrote:
> While I wholeheartedly agree plugins, clean separation of concerns, discreet
> repos, all have big benefits if every single developer installs a plugin on 
> day 1 that
> is specific to a particular platform I feel that might be a good indication 
> the
> platform should conditionally roll that plugin in.
> I think the statusbar might quality.
> 

Good point, IMHO it's more part of a popular 'core' web dev flow:
cordova plugin add org.apache.cordova.web-dev  (include statusbar & 
console.log, others?)

Arguably a CSS fix works too:
http://stackoverflow.com/questions/18886195/ios-7-status-bar-overlapping-ui

 Some related frustration:
cordova create bar
cordova platform add android

Import 'plaforms/android' into Eclipse:
https://onedrive.live.com/?gologin=1&mkt=en-US#cid=295047487FC4F731&id=295047487FC4F731%215602&v=3

Broken... but "cordova run" works... Is using eclipse still a 'core' thing?
It's a "still want to use an IDE" thing. My preference is a cordova that 
embraces diversity. 

Back to statusbar, some might prefer native code through xcode / not using the 
plugin.

RE: [cordova-plugins/statusbar] Publishing as core

[Jonathan Bond-Caron]

On Mon Mar 10 12:51 PM, Michal Mocny wrote:
> 
> I think we can solve that problem using a plethora of better
> alternatives, including
> install scripts (perhaps with a generator
> like yeoman, perhaps my just pasting
> snippets in tutorials), by
> supporting plugin dependencies for platforms, or just by
> hard coding
> a list of default plugins in cordova-cli (we do this in cca for
> example).
> Many alternatives exist.
> 

Kind of agree, I like the idea of keeping plugins outside of platforms.

What Cordova needs is better "default workflows", e.g.

cordova platform add android
cordova plugin add chrome-web-dev  (install script sets up what you need + 
dependencies)

cordova platform add windows8
cordova plugin add microsoft.net-dev  (install script sets up what you need + 
dependencies)

With this in mind, I think it's a little more obvious how upstream 
distributions could diverge from cordova.

In that sense, I'm -1 to:
supporting plugin dependencies for platforms

RE: Proposal: hooks support for plugins

[Jonathan Bond-Caron]

On Thu Mar 6 01:57 PM, Sergey Grebnov (Akvelon) wrote:
> Can we think about scripts as just a new plugin module?  - Similar to
> js-module or
> config-file and which must be processed special way (by
> execution).
> 
>   src="src/windows8/SQLitePCL.Ext.dll" custom="true"/>  src="src/add_win8_toastCapable.js"/>
> 
> 
> Not so powerful and cool, but easy to implement and understand. During
> uninstall each script is called again but with 'uninstall' flag (or each
> script file can
> emit install and uninstall functions)
> 

I'm all for simple, what happens if one of those scripts fails? E.g. failed 
compile

For example in cli:

cordova plugin add sqlite
platforms = ['android', 'windows8'];
for(p in platforms)
installPlugin('sqlite');  // android ok! windows8 fails at 
'src/compile_sqlite.js'

Is 'sqlite' at that point installed on android? Do we rollback the install? Run 
the uninstall() scripts? 

For that reason, sandbox idea seems less chaotic with some hookApi - which 
would cleanup properly if something goes wrong... 

What you're suggesting seems like it could work, until something goes wrong and 
leaves the platform(s) project/native in an inconsistent state. Multiple that 
with "pluginb" that fails at 'src/compile_stuff.js'

Could be doable but not sure well it would work.

RE: Proposal: hooks support for plugins

[Jonathan Bond-Caron]

On Thu Mar 6 11:41 AM, Michal Mocny wrote:
> On Thu, Mar 6, 2014 at 11:16 AM, Jonathan Bond-Caron <
> jbo...@gdesolutions.com> wrote:
> 
> > On Wed Mar 5 04:13 PM, Michal Mocny wrote:
> > > For cli workflow: hooks (including plugin hooks) can access
> > > config.xml 's for things like the sqllite compile
> > > example (recompile
> > only if
> > > settings changed would be nice), and access  at runtime
> > > for
> > the
> > > console example.
> > >
> > > For old workflow, perhaps sqllite is documented to manually run the
> > > hook
> > to
> > > recompile whenever you want to change the default setting?
> > >
> > > Just thinking about alternatives and/or solutions that are actually
> > feasible short
> > > term.
> > >
> >
> > Ya it could work, maybe something like:
> >  > value="--prefer-console true" /> (passed to an install script)
> >
> 
> Thats not what I am suggesting.  I am suggesting:
> 
>  
> 

So...




Looks like a windows registry to me, build a tree from it.
Heck, everything is just a preference (sarcasm):



Ultimately 'preference' tag always wins.

Joke aside, the part that's special about the plugin hooks is a need to track 
installed files for uninstall() & the security issue (sandbox or not).

RE: Proposal: hooks support for plugins

[Jonathan Bond-Caron]

On Wed Mar 5 04:13 PM, Michal Mocny wrote:
> For cli workflow: hooks (including plugin hooks) can access config.xml
> 's for things like the sqllite compile example (recompile only if
> settings changed would be nice), and access  at runtime for the
> console example.
> 
> For old workflow, perhaps sqllite is documented to manually run the hook to
> recompile whenever you want to change the default setting?
> 
> Just thinking about alternatives and/or solutions that are actually feasible 
> short
> term.
> 

Ya it could work, maybe something like:
 (passed to an install script)

Keep in mind 'install' options/config (only used once during the install 
process) aren't the same as 'runtime' options/config (dynamic, changed by user)

 (runtime 
options?)


Some high level code at how the install script could work:
https://github.com/jbondc/cordova-labs/blob/master/cordova-plugin-echo/plugin.xml#L14
https://github.com/jbondc/cordova-labs/blob/master/cordova-plugin-echo/src/preinstall.js

Not sure if we need a 'postinstall' script, instead in the preinstall.js could 
do something like:
project.onPostInstall('plugin.name', function(hookApi){

 // do something else..

});

Many ways it could work, this is more pursuing the sandbox idea. 

RE: Proposal: hooks support for plugins

[Jonathan Bond-Caron]

On Wed Mar 5 02:54 PM, Jesse wrote:
> I am a no to passing arguments, the use-case is really about doing some
> extra
> tasks for the current environment.
> 

Not necessarily:
https://github.com/apache/cordova-plugin-console/blob/master/www/logger.js#L48

cordova plugin add cordova-plugin-console --use-console true (preinstall script 
tries to keep console.log on platforms where it exists)

It's also about options to support different workflows.

For sqlite (which would be awesome btw), it's also enabling/disabling default 
compile options:
https://sqlite.org/compile.html

I'm not saying this can be done short term or that the extra complexity is 
worth it but should consider looking into it...

RE: Proposal: hooks support for plugins

[Jonathan Bond-Caron]

On Wed Mar 5 12:00 PM, Marcel Kinard wrote:
> In that case (i.e., "npm test") the user is explicitly invoking the
> script. If we are
> talking about hooks that run automatically on
> "cordova plugin add", then it is
> implicit. How about if the cli
> prompted the user when a hook request is present
> such as "plugin
> foobar wants to run the script xyz. Do you grant permission for it
> to
> do so?" Perhaps plugman could have an --accept-scripts parm that
> granted
> permission to all such requests to prevent prompting?

Could run scripts in a 'sandbox' of some sort...
http://nodejs.org/api/vm.html

Might be a little safer and less chaotic in terms of what scripts can install, 
that way uninstall() can cleanly do its job.

RE: Proposal: hooks support for plugins

[Jonathan Bond-Caron]

On Sat Mar 1 01:39 PM, Sergey Grebnov (Akvelon) wrote:
> 
> 
> 
> preinstall.js is called before plugman.raw.install(platform, platformRoot,
> path.basename(dir), pluginsDir, options) and could be used to check system
> requirements, download/compile required libraries, etc
> 
> afterinstall.js is called after and could be used  to add/configure 
> additional project
> references,  etc uninstall.js - for discussion, could be used for clean up, 
> etc
> 
> As for required parameters I think we should pass at least application folder 
> and
> target platform.
> 
> Thoughts? Propose to discuss this on the monthly sync, Mar 4, 2014 (7pm EST)
> 

Two issues I can think of:
- uninstall() needs to know which files where installed by either the 
preinstall or afterinstall script.
- I'd like users to be able to pass options/arguments to the script (overriding 
default build options)

e.g.
cordova plugin add some.db --utf8 false

For unix people, it's like a ./configure --utf8 false --with-stuff && make 
install

But can't do this right now with cordova since we'd need to store the plugin 
install arguments "--utf8 false" to update a plugin.

RE: get config.xml data from js

[Jonathan Bond-Caron]

On Mon Mar 3 12:45 PM, Brian LeRoux wrote:
> sure, but that is most certainly a user space instrumentation and done
> very easily
> with a hook
> 
> do ALL apps need that instrumentation? probably not
> 

Fair enough, don't have a strong opinion about it. 

Is the list of installed plugins & versions in cordova_plugins.js more 'core' ?

RE: get config.xml data from js

[Jonathan Bond-Caron]

On Sat Mar 1 02:19 PM, Brian LeRoux wrote:
> No, no, I'm suggesting this is a user space problem. Easily solved by
> the user.
> (Certainly the first/only time I've heard a desire for this
> feature.) 

Here's a very common use case:

- error occurs
- send application info to a central server
  Usually here you need app name, version and other config params (e.g. android 
hardware acceleration)

Seems like a core kind of thing not something users should figure out.

You probably don't need to expose all the configuration params in the webview, 
but a couple of them are useful.

RE: get config.xml data from js

[Jonathan Bond-Caron]

On Fri Feb 28 04:06 PM, Michal Mocny wrote:
> Now that I look a bit deeper, that plugin I only returns 
> specifically,
> not the entire contents of config.xml (name is not a
> ).
> 
> It also does not currently implement a way to inspect all preferences,
> just has a
> way to get the value for a specific one.
> 
> I do think it would be a good idea to just have one core plugin (perhaps
> extend
> that one I linked) to include all config file values.
> 
> Filed: https://issues.apache.org/jira/browse/CB-6139
> 

Could also be added cordova_plugins.js
https://github.com/apache/cordova-plugman/blob/master/src/prepare.js#L220

pluginMetadata['config'] = {...}

See part about "runtime meta":
https://wiki.apache.org/cordova/config/cordova.xml

Note change for "icons" to align with:
http://www.w3.org/TR/2013/WD-appmanifest-20131217/

RE: CB-6028: Fix for infinte loop in plugman with plugins with cyclic dependencies

[Jonathan Bond-Caron]

On Fri Feb 28 10:18 AM, Martin Bektchiev wrote:
> My first idea was to allow the installation of such interdependent plugins, 
> but
> then I saw that once added they cannot be uninstalled due to the cylce in the
> graph. That's why I decided to stay consistent with uninstall and not allow 
> it.
> 

Gotcha, I guess it works for now.  Eventually I'd like to get rid of dep-graph 
and store the deps tree in json.

RE: CB-6028: Fix for infinte loop in plugman with plugins with cyclic dependencies

[Jonathan Bond-Caron]

On Fri Feb 28 08:09 AM, Andrew Grieve wrote:
> Thanks Martin! Looks good! I've merged it in :)
> 
> 

Should just keep track of what's pending to be installed, why throw an 
exception?

RE: plugman testing

[Jonathan Bond-Caron]

On Wed Feb 26 09:24 AM, Gert-Jan Braas wrote:

> >>  expect(s).toHaveBeenCalledWith(temp,
> >> path.join('src', 'plugins', 'dummyplugin', 'DummyPlugin.js'));
> >>  done();
> >>   });
> >>  });
> >>  });
> >>
> >
> > Jasmine runs synchronously, so you need to 'waitsFor' promise:
> >
> 
> Ok thanks.
> Will look that up. First I will try to look what's going on thoug. The 
> 'waitFor' is not
> needed in the tests for the other platforms, so I don't expect it to be for
> Firefoxos also. Correct me if I'm wrong.
> 

So I take that back,
 
Looks like jasmine supports calling done() to wait for an async test 
(documented in 2.0). 

Seems like the better way to go.

RE: plugman testing

[Jonathan Bond-Caron]

On Tue Feb 25 03:24 AM, Gert-Jan Braas wrote:
> I've added some testing for firefoxos in plugman, but am a bit stuck on
> the
> uninstall handler.
> 
> test:
>  describe('of  elements', function() {
>  it('should remove stuff by calling common.removeFile',
> function(done) {
>  var s = spyOn(common, 'removeFile');
> 
>  install('firefoxos', temp, dummyplugin, plugins_dir, {})
>  .then(function() {
>  var source = copyArray(valid_source);
>  firefoxos['source-file'].uninstall(source[0], temp);
>  expect(s).toHaveBeenCalledWith(temp,
> path.join('src', 'plugins', 'dummyplugin', 'DummyPlugin.js'));
>  done();
>   });
>  });
>  });
> 

Jasmine runs synchronously, so you need to 'waitsFor' promise:

runs(function() {
setDonePromise( install('firefoxos', temp, dummyplugin, 
plugins_dir, {})  )
});
waitsFor(function() { return done; }, 'install promise never 
resolved', 200);
runs(function() {
var source = copyArray(valid_source);
 firefoxos['source-file'].uninstall(source[0], temp);
expect(s).toHaveBeenCalledWith(temp,path.join('src', 'plugins', 
'dummyplugin', 'DummyPlugin.js'));
});

This example might help:
https://github.com/jbondc/cordova-plugman/blob/master/spec/install.spec.js#L115

>   - how is e.g.
>   require('../plugman').emit('verbose', 'Install complete for ' +
> plugin_id + ' on ' + platform + '.');
> controled? can i set the emit level and where can i find it's output?


It's a wrapper for node's event emitter:
https://github.com/apache/cordova-plugman/blob/master/src/events.js
https://github.com/jbondc/cordova-plugman/blob/master/plugman.js#L58

By itself it doesn't "log" anything, just tracks events. You to map events to 
console.log()

An example here:
https://github.com/jbondc/cordova-plugman/blob/master/spec/common.js

cd spec
node-jasmine test.spec.js -d verbose

> Can it be used running tests (npm test)?

Would be nice, npm parses the commands on its own so doesn’t delegate any flags 
etc.. related to:
https://github.com/npm/npm/issues/3494

RE: cordova launcher icon support https://github.com/apache/cordova-cli/pull/126

[Jonathan Bond-Caron]

On Fri Feb 21 09:43 AM, Axel Nennker wrote:
> 
> I would like to avoid to invent new elements or attributes. I think my plan 
> works
> and would like to know what the group thinks about it.
> 

The "icon problem" is you can have different icons of the same size for 
different platforms.

The cordova config has data model problem, there's no magical code generation 
that's going to solve that.

RE: Engine confusion

[Jonathan Bond-Caron]

On Wed Feb 12 02:12 PM, Tim Kim wrote:
> 
> 
> Yep, Braden is correct. That is totally a bug.  Filed here:
> https://issues.apache.org/jira/browse/CB-6023
> 

Thoughts on?


Vs.

 

I'm trying to look at how this can apply to 'runtimes'. E.g.




Vs.
 ?

RE: cordova launcher icon support https://github.com/apache/cordova-cli/pull/126

[Jonathan Bond-Caron]

On Fri Feb 21 09:14 AM, Jonathan Bond-Caron wrote:
> On Thu Feb 20 04:07 AM, Axel Nennker wrote:
> > How about this strategy:
> >
> 
> Would this work:
>   ref="icons" src="icon.jpg" width="96" height="96" />  ref="splashscreens" src="splash.jpg" width="1024" height="768" />
> 
> 
>
> 
> 
> The cdv: prefix in the only clean way to get to something useful in 4.0
>

In 4.0, it becomes:
 
 

RE: cordova launcher icon support https://github.com/apache/cordova-cli/pull/126

[Jonathan Bond-Caron]

On Thu Feb 20 04:07 AM, Axel Nennker wrote:
> How about this strategy:
> 
> project_dir/config.xml
> - no new elements in config.xml like cdv:icon
> - no new attributes in icon element in config.xml like cdv:platform or
> gap:platform
> - do not invent stuff we have to support for the rest of our life.
> 
> On all platforms:
> - if config.xml contains a  without any attributes 
> like
> width and heigth, then copy that src to to all platform specific  locations 
> where

Would this work:





   
 

The cdv: prefix in the only clean way to get to something useful in 4.0

RE: XML Namespaces

[Jonathan Bond-Caron]

On Sat Feb 15 01:56 PM, Dick Van den Brink wrote:
> I like the idea of json config files but how to handle cases where a element 
> can
> occur multiple times? With only one element, it would generate an object, but
> with multiple elements it would change into an array. This might make the code
> which reads the config a bit more difficult/error prone because it needs to 
> check
> the type everytime.
> What do you guys think? Or is this a non-issue? Btw, I took a part of a 
> plugin.xml
> as an example.
> Xml:
> 
> 
>   Jason (array
> because engine element is found multiple times):

Good point,

It's more an issue with xml2js:
https://github.com/Leonidas-from-XIV/node-xml2js/blob/master/src/xml2js.coffee#L210

Could add an option for type conversion:
https://github.com/Leonidas-from-XIV/node-xml2js/blob/master/src/xml2js.coffee#L160

if (@options.jsType['array'][key])
   obj[key] = [newValue]

Not perfect since all 'engine' tags would be an array but should be good  
enough for Cordova.

Or do the conversions in the 'cleanup', if( typeof json['engines']['engine'] != 
'array') json['engines']['engine'] = [json['engines']['engine']];
https://github.com/jbondc/cordova-labs/blob/master/cordova-lib/config.ts#L52

Looks fixable either way,
J

RE: XML Namespaces

[Jonathan Bond-Caron]

On Mon Feb 17 05:27 PM, Brian LeRoux wrote:
> almost certain we could align down to a single configuration for
> everything safely
> extending package.json (and treating
> ./platform/whatever/[...]/www/config.xml
> as compile targets
> 

Sounds right, package.json is the top level config?

RE: XML Namespaces

[Jonathan Bond-Caron]

On Mon Feb 17 04:13 PM, Jesse wrote:
> If this only refers to the cli project level config, then I withdraw my
> objection.
> 

config.json or config.xml would be top-level in the cli project

> However, consistency creates clarity.
> 
> Maybe taking a step back, why do we have different config.xml files per
> platform
> anyway? Given that they are all following the same spec (
> our modified widget
> spec ) shouldn't they all be capable of reading
> feature/param[@name="X"] and
> only applying the preferences they
> support?
> 
> 

Everything would be generated based on what the platforms need. 
e.g.
helloworld/config.json
helloworld/platforms/windows8/config.xml
helloworld/platforms/android/res/xml/config.xml
helloworld/platforms/firefoxos/www/wat.json (manifest.json?, package.json?)

Looking at firefoxos, only need the 'runtime meta' and pushing configuration 
options in there.
Hopefully eventually the cordova 'meta' stuff goes away.

Note: Android could be changed to read it's cordova config from "www/wat.json", 
ultimately that's the only 'standardish' file platform webviews/runtimes should 
be reading.
json['meta']['cordova']['config']['log-level']
json['meta']['cordova']['config']['access-origin'][0]
...

The goal of the top-level config is to have enough info to generate meta that 
the platforms can read. 

In an ideal world, there's only two files:
helloworld/config.json
helloworld/platforms/windows8/www/w3c-standard.json

or
helloworld/config.xml
helloworld/platforms/windows8/www/w3c-standard.json

RE: XML Namespaces

[Jonathan Bond-Caron]

On Mon Feb 17 11:07 AM, Marcel Kinard wrote:
> Just curious, what drives your preference for XML over json?
> 

It fits more naturally with some 'native' tools (e.g. android & windows 8). 
IDE's have better support for it.

If you're developing only with css,js,html -> json makes more sense
If you're developing using native tools (plugman flow) -> xml makes more sense

Exception is probably firefoxos, json all the way.

RE: XML Namespaces

[Jonathan Bond-Caron]

On Mon Feb 17 10:41 AM, Marcel Kinard wrote:
> 
> On Feb 15, 2014, at 1:34 PM, Jonathan Bond-Caron
>  wrote:
> 
> > So the idea here is:
> > - config.xml, config.json
> > - plugin.xml, plugin.json
> >
> > Would both be supported, with json being looked for first.
> 
> Would the intention be to eventually deprecate the xml after a "seamless"
> transition period, or to keep the xml around for the foreseeable future?

That's a good question... personally I still prefer XML over json. I would say 
keep the xml around for the foreseeable future,

If nobody uses it, drop it eventually.

RE: XML Namespaces

[Jonathan Bond-Caron]

On Fri Feb 14 02:30 PM, Marcel Kinard wrote:
> 
> On Feb 13, 2014, at 10:04 AM, Jonathan Bond-Caron
>  wrote:
> 
> > IBM most likely would prefer XML for the XSD & tooling...
> 
> Not necessarily. Schema validation is nice, but XML for the sake of XML 
> doesn't
> make sense. What makes more sense is following standards where reasonably
> possible. But if the widget spec is deprecated and we are making a conscious
> decision to abandon it, then the leaning for XML goes away. Given the audience
> of web devs, and the use of json config in other places, my preference would 
> be
> for json config. 

Great to have your opinion, my guesswork was that for a plugman based project 
on android for example, xml would be preferred.

> 
> > Note about xml vs. json config, Cordova could support both.
> 
> Cordova could, but that seems to me like overkill. If someone really wants 
> xml,
> how about providing an xslt that translates the xml to json, so they can 
> author in
> xml and Cordova could read json. But even that sounds like overkill too.

It turns out there's a great node lib called 'xml2js', the code to do this is 
pretty simple:
https://github.com/jbondc/cordova-labs/blob/master/cordova-lib/test.js

https://github.com/jbondc/cordova-labs/blob/master/cordova-lib/config.ts
https://github.com/jbondc/cordova-labs/blob/master/cordova-lib/config.js

So the idea here is:
- config.xml, config.json
- plugin.xml, plugin.json 

Would both be supported, with json being looked for first.

RE: XML Namespaces

[Jonathan Bond-Caron]

On Thu Feb 13 10:49 AM, Braden Shepherdson wrote:
> 
> except for the persistent question of what we're gaining with all these 
> changes.
> Like the JSON config files idea, I'd be happy if we were already in that 
> world. But
> the transition is sufficiently painful that switching doesn't feel worth it; 
> we don't
> gain enough to justify the pain.
> 
> However! That only applies to the configuration file reshuffling. If we 
> really can
> refactor Plugman's flows to have reversible transactions, that would 
> definitely
> make me happy. But I don't think we should conflate the config changes and 
> that
> refactoring - they're independent. We would need to expand the metadata
> tracked by plugman, of course, but that's not the same as moving all the
> configuration.
> 

Agree that some plugman refactoring isn't related to config changes.
But some work would involve converting plugin.xml --> project.json  (installed 
metadata)

I'd argue we gain a lot by doing this, there's so much IO going on to keep the 
installed plugin.xml files around and reading those files. 
In comparison to a single project.json, that's a big benefit.

If there's going to be code written to map xml to json, it makes sense to work 
on 1-1 mapping of xml & json config files in 1 swoop.

Added a section on preferences around xml or json:
https://wiki.apache.org/cordova/config/cordova.xml

Ultimately the bit I think is important is dropping the widget spec, it's 
counter-productive.
 

RE: XML Namespaces

[Jonathan Bond-Caron]

On Thu Feb 13 09:37 AM, Andrew Grieve wrote:
> Jonathan - I'm a fan of your "rough work" :)
> 

Thanks, lots of credit to Braden & Mark around the plugman 'project' idea

Note about xml vs. json config, Cordova could support both. Upstream 
distributions could choose to focus on config as XML, json or both.
IBM most likely would prefer XML for the XSD & tooling, Adobe could do XML for 
enterprise... json for web devs, ...?

Don't think there's a silver bullet there.

> Reason I'd want to use  instead of  for now, is to minimize 
> the
> number of "cdv:"s that appear. If you namespace the element, you don't need to
> namespace the attributes. It also makes  and 
> more similar.

Makes sense, the work on cdv:icon could be pushed into the 4.0 config (with no 
namespace).

RE: Engine confusion

[Jonathan Bond-Caron]

On Wed Feb 12 10:22 PM, Andrew Grieve wrote:
> > b) More a personal preference for:
> >   > version=">=3.3.0" platform="android"/>
> >
> > I can patch the code so that:
> >   > name="cordova-{$supported_platform} " version=">=3.3.0" />
> >
> >
> - Agree that the first example is more intuitive.
> - Based on our 3.0+ version scheme, it's possible for cordova-ios= 4.0 while
> cordova-cli = 3.5. So, another option here is to make cordova-ios check
> platforms/ios/cordova/version and "cordova" use CLI's version
> 

I think I appropriately picked the e-mail topic :)

I prefer:



Before it implies cordova is the "engine"




Implies there's 1+ cordova engines, which I'm not really sure what that means.

It's really "cordova" engine for platform "foo"


Odd part in the code is "cordova" check gets dropped *if* "cordova-platform" 
exists:
https://github.com/jbondc/cordova-plugman/blob/master/src/install.js#L212

I don't think that how people expect it to work, hence the confusion. "cordova" 
doesn't refer to the cordova-cli version

J

RE: XML Namespaces

[Jonathan Bond-Caron]

On Wed Feb 12 05:00 PM, Andrew Grieve wrote:
> So... I'd like to:
> A: Remove  xmlns="http://www.w3.org/ns/widgets"; from our config.xml
> template
> B: Change xmlns:cdv="http://cordova.apache.org/ns/1.0"; -> xmlns="
> http://cordova.apache.org/ns/1.0";
> C: Revert the commit that enforces the namespace to exist.
> 
> This will allow us to add new tags & attributes to cordova.xml without
> "violating"
> XML namespace rules.
> 
> Does anyone hate this idea?

+1 for dropping widget spec in 4.0

Issue with the widget spec is it doesn't take into account multiple platforms, 
or possibly different runtimes.
A 'cordova app' is more similar to a plugin.xml (needs to be ported to multiple 
platforms).

Some rough work here:
https://wiki.apache.org/cordova/config/cordova.xml

Using the widget spec as-is looks like a lowest-hanging fruit experience on 
multiple platforms.

You need lots of xmlns:cdv, xmlns:gap, ... stuff to bridge the gap.

Short term (3.x):
-1 to A,B,C
- add xmlns:cdv for custom icons, ...?

Long term (4.x)
- New cordova config file
- Provide migration path of cordova 3.x project -> 4.x

RE: Engine confusion

[Jonathan Bond-Caron]

On Wed Feb 12 03:56 PM, Braden Shepherdson wrote:
> Do the check the same file? I thought they were different. They might
> check the
> same path in different platforms, but that script can
> return different things. I
> would consider that a bug as well.
> 
> I don't see anything to be gained from changing the syntax.
> 

They check the same *relative file* to the platform/project directory (so ya 
can have different version script per platform).
Makes sense it was done that way in the beginning but could be improved now.

a) Issue is other/newer platforms don't have the 'check for version x'. 

b) More a personal preference for:
 


I can patch the code so that:



Still works but is deprecated for 4.0

If "cordova" is meant to check the cli version, from what I can tell hasn't 
been that way since Aug 2013

J

RE: Engine confusion

[Jonathan Bond-Caron]

On Tue Feb 11 11:05 AM, Braden Shepherdson wrote:
> The intention is that it allows plugins to specify that they require at least 
> a certain
> version of the native code for each platform. This would be for things like 
> added
> a new transport type to the bridge, as when we added binary data transmission
> on iOS and Android a year or so ago. Any plugins published that relied on it 
> would
> specify at least that level of cordova-android and cordova-ios, whichever 
> releases
> the changes made it into. It turns out that the native code is stable enough 
> that
> this is hardly ever relevant.
> 
> Answering your questions:
> - The cordova-plugman version returning node's version sounds like a bug.
> It should be Plugman's NPM version number so far as I know.
> - Very few. Most of the significant changes happened several versions ago; in
> most cases ">= 3.0" is sufficient.
> - Build time (more precisely, plugin install time). There are currently no
> constraints or checks for eg. what versions of Android a plugin supports.
> - This is true even of the "cordova" one, which is actually the version 
> of the
> `cordova` CLI tool if memory serves.
> 

Thanks, patch is here:
https://github.com/jbondc/cordova-plugman/blob/master/src/util/default-engines.js

Seems like there should only be "cordova" and not "cordova-ios", 
"cordova-android", "cordova-*", they check the same 'script' file
Maybe it was different in 2.x?




Equivalent to:

Engine confusion

[Jonathan Bond-Caron]

I'm a bit confused about 'engines'

To my surprise, "cordova-plugman" actually returns node's version:
https://github.com/apache/cordova-plugman/blob/master/src/util/default-engines.js

Some questions:

-  Should "cordova-plugman" be renamed to "node"?

-  Are there many plugins that depend on "version x" of 
cordova-android, cordova-ios, xcode, ...?

-  Are 'engines' meant be build time requirements vs. runtime 
(~webview) requirements?



It all looks like build time, with the exception of "cordova" where cordova.js 
exec() is required by the plugins.

J

RE: [Android] SecureToken/NoFrak feature addition

[Jonathan Bond-Caron]

> > https://labs.mwrinfosecurity.com/blog/2013/09/24/webview-addjavascript
> > interface-remote-code-execution/
> >
> > > I don't know enough about the reasons for the different bridges to
> > > know whether this is a good idea or not.
> > >
> >
> > This is why we can't have nice things!
> >
> 
> Ouch... that's a good reason to disable that bridge completely for APIs < 17; 
> never
> mind whether noFrak is enabled or not. If it's likely that 
> addJavascriptInterface
> has other holes like this, then we should talk about removing it entirely.
> 

Seems harsh to disable that bridge completely: "The following JavaScript, *if 
injected into a WebView*"

This is nothing new, third party 

RE: cli & plugman - optimist, nopt - refactoring

[Jonathan Bond-Caron]

On Wed Jan 29 10:19 AM, Braden Shepherdson wrote:
> I use CoffeeScript all the time in my own hackery. In Cordova, though,
> big
> -1 to alternative languages. Let's keep it straight Javascript.
> 

Also -1 on CoffeeScript / alternative syntax.

TypeScript though is the new version of JavaScript, EcmaScript 6 / no new 
language syntax to learn.
Well more accurately it's EcmaScript 6 + "type hints", but very similar to the 
new spec.

The design I had in mind is something like:

cli.js
var cordova = require("cordova-library");
var command = new cordova.Cli(argv);

plugman.js
var cordova = require("cordova-library");
var command = new cordova.Plugman(argv);

Both cli & plugman npm packages would depend on the library.

RE: Hangout?

[Jonathan Bond-Caron]

Video call full?

Great to see some faces,
Cheers,
Jon

> -Original Message-
> From: John M. Wargo [mailto:jwarg...@gmail.com]
> Sent: January 29, 2014 12:36 PM
> To: dev@cordova.apache.org
> Subject: Re: Hangout?
> 
> Me too. I dropped off because I didn't' want to eat up a slot.
> 
> On 1/29/2014 12:30 PM, Lisa Seacat DeLuca wrote:
> > What's the URL for the non-live people.  The listeners?  I dont' want to 
> > take up a
> spot for larger groups but I'd like to listen in.
> >
> >
> >
> > *Lisa Seacat DeLuca*
> > Emerging Mobile Software Engineer - IBM Master Inventor SWG Emerging
> > Internet Standards
> > --
> > --
> > --
> > --
> > --
> > --
> > --
> > --
> > --
> > --
> > --
> > --
> > --
> > --
> > -- *Phone:*1-410-332-2128| *Mobile:*1-415-787-4589*
> > E-mail:*_ldel...@us.ibm.com_ * personal
> > website: *_lisaseacat.com_ *
> > Chat:*Sametime: ldel...@us.ibm.com *
> > Find me on:*LinkedIn: http://www.linkedin.com/in/lisaseacat
> Twitter: https://twitter.com/LisaSeacat
> *and within IBM on:*IBM Connections:
> https://w3-connections.ibm.com/profiles/html/profileView.do?key=2e1afd56-
> daa9-428e-8f4a-2fa7516940c0  connections.ibm.com/profiles/html/profileView.do?key=2e1afd56-daa9-428e-
> 8f4a-2fa7516940c0>
> > IBM
> >
> > 100 East Pratt St 21-2212
> > Baltimore, MD 21202-1009
> > United States
> >
> >
> >
> >
> >
> >
> > From: Andrew Grieve 
> > To: dev 
> > Date: 01/29/2014 12:28 PM
> > Subject: Re: Hangout?
> > Sent by: agri...@google.com
> > --
> > --
> > --
> > --
> > --
> > --
> > --
> > --
> > --
> > --
> > --
> > --
> > --
> > --
> > --
> >
> >
> >
> > Come on in!
> > https://plus.google.com/hangouts/_/hoaevent/AP36tYf6UPXu7iH0JI5udIQwnb
> > Lx1JBdZw7XFq7Mdb3-BkZ3gvKh8A?authuser=0&hl=en-GB
> >
> >
> > On Wed, Jan 29, 2014 at 12:25 PM, Ken Wallis 
> wrote:
> >
> > > Yup, Steve is just getting setup
> > >
> > > Sent from my BlackBerry 10 smartphone.
> > >   Original Message
> > > From: Wargo, John
> > > Sent: Wednesday, January 29, 2014 9:21 AM
> > > To: dev@cordova.apache.org
> > > Reply To: dev@cordova.apache.org
> > > Subject: Hangout?
> > >
> > >
> > > The hangout is in a few minutes, right?
> > >
> > > John M. Wargo
> > > Twitter: @johnwargo
> > >
> > >
> >

RE: Chrome Apps via Cordova

[Jonathan Bond-Caron]

Great stuff :)

> -Original Message-
> From: agri...@google.com [mailto:agri...@google.com] On Behalf Of Andrew
> Grieve
> Sent: Tuesday, January 28, 2014 12:18 PM
> To: dev
> Subject: Re: Chrome Apps via Cordova
> 
> http://blog.chromium.org/2014/01/run-chrome-apps-on-mobile-using-
> apache.html
> 
> 
> On Mon, Jan 27, 2014 at 10:55 PM, Carlos Santana
> wrote:
> 
> > Good job guys, this is really great !!!
> >
> >
> > On Mon, Jan 27, 2014 at 6:33 PM, Steven Gill 
> > wrote:
> >
> > > This is rad! Great job!
> > >
> > >
> > > On Mon, Jan 27, 2014 at 2:55 PM, Brian LeRoux  wrote:
> > >
> > > > this is nice stuff guys / love it
> > > >
> > > >
> > > > On Mon, Jan 27, 2014 at 1:04 PM, Andrew Grieve
> > > > 
> > > > wrote:
> > > >
> > > > > The Google team's side-project has made some good progress in
> > > > > the
> > last
> > > > > while. We've shared this before, but we're gearing up for a blog
> > > > > post
> > > > about
> > > > > it so wanted to share it again :)
> > > > >
> > > > > https://github.com/MobileChromeApps/mobile-chrome-apps
> > > > >
> > > > > npm install -g cca
> > > > > cca create MyProject
> > > > >
> > > > > At this point you have a Chrome App within your www/ that you
> > > > > can
> > > build &
> > > > > publish to the Chrome Web Store. You can also use "cca" the same
> > > > > as "cordova" to build & run it as a Cordova app.
> > > > >
> > > >
> > >
> >
> >
> >
> > --
> > Carlos Santana
> > 
> >

cli & plugman - optimist, nopt - refactoring

[Jonathan Bond-Caron]

A bit of context, I've been digging more into adding -force or -f to forcefully 
remove plugins (supported by plugman & cli)

As I was bouncing in between cli & plugman code, I felt an itch on some issues:

-  In cli, options is passed as an array to the 'subcommands' which is 
confusing as it's an object everywhere else

IMHO, options should always be an object & the subcommands shoudn't need to do 
more parsing



-  Cli uses 'optimist' for command line parsing, plugman 'nopt'

-  Lots passing 'options' gymnastics into other functions

Long story short, I ended up refactoring a lot of the code:
https://github.com/jbondc/cordova-cli/compare/apache:master...master
https://github.com/jbondc/cordova-plugman/compare/apache:master...master

Notable changes:

-  cli now uses 'nopt' to parse command line arguments

-  hooks & build methods are passed a 'command' which is also an object

-  took out a callback christmas tree:

https://github.com/jbondc/cordova-plugman/blob/ad2c74b3344c8899e8ede12827f7ca4637a01b6f/src/install.js#L306

(there was a bug in there where Q() fails to emit/report the Error)

-  lots of testing, though some tests are still failing

-  Removed 'mock' tests for plugman uninstall which uncovered bugs with 
the removal/re-install of plugins from a path

-  I tried to keep to changes around consistency

Objectives of these changes (big patch) would be to:

-  Swap code to use 'command' from an external library (shared by cli & 
plugman):

https://github.com/jbondc/cordova-labs/blob/master/cordova-lib/command.ts

Before I continue to get the remaining tests passing, wanted to get some 
feedback:


-  Should I split the patch in multiple pieces? How?

-  Anything I'm overlooking or some objections with it?

-  Any thoughts on using TypeScript or Coffeescript as a library (e.g. 
cordova-lib)?

Cheers,
Jon

Ps: should be joining the hangout tomorrow

RE: Cordova and Crosswalk

[Jonathan Bond-Caron]

On Sun Dec 8 06:13 PM, Brian LeRoux wrote:
> I like it but one small nit: we already use the term 'engine' to
> describe a
> downstream in plugins. Propose we call it 'renderer'.
> 
> 

Would 'runtime' be better?  Renderer might be too specific. A different 
'runtime' could mean same HTML5 rendering layer but different storage mechanism 
or hardware drivers. 

I went through another iteration:
https://wiki.apache.org/cordova/Platform%20Engine#preview

After some thinking about the 'browser' platform, I'd propose a 'dev' platform.
It would auto-detect the OS and just launch the browser 'runtime'.
In that sense, both the browser & ripple would be runtimes of the 'dev' 
platform.

For plugin authors, it would be easy to write JavaScript-only plugins by 
targeting the 'browser' runtime:

   
   
   

Each platform would have a default runtime of 'default' or 'native', all 
compatible with the 'browser' runtime.

Implementation wise, I'm not sure what his means for the plugin repository. 
Dependency management would need to resolve which runtimes are compatible for a 
platform and allow fetching those plugins.

RE: Cordova and Crosswalk

[Jonathan Bond-Caron]

On Wed Dec 4 11:55 PM, Hu, Ningxin wrote:
> > -Original Message-
> > From: Jonathan Bond-Caron [mailto:jbo...@gdesolutions.com]
> > Sent: Wednesday, December 04, 2013 11:47 PM
> > To: dev@cordova.apache.org
> > Subject: RE: Cordova and Crosswalk
> >
> > On Tue Dec 3 08:40 AM, Hu, Ningxin wrote:
> > > Your thoughts about the integration?
> > > Is it possible to support Crosswalk runtime as a platform in Cordova
> > > upstream?
> > >
> > > [2]: https://github.com/crosswalk-project/crosswalk-cordova-android
> >
> 
> So do you agree that the first step is to make Cordova Android engine
> exchangeable?
> 

That's what would make sense to me, might be other ways to do it.

I put up the thoughts here:
https://wiki.apache.org/cordova/Platform%20Engine

RE: Cordova and Crosswalk

[Jonathan Bond-Caron]

On Tue Dec 3 08:40 AM, Hu, Ningxin wrote:
> Your thoughts about the integration?
> Is it possible to support Crosswalk runtime as a platform in Cordova
> upstream?
> 
> [2]: https://github.com/crosswalk-project/crosswalk-cordova-android

It looks really awesome, can't wait to try it out.

I have some concerns about more platforms and the terminology. 
Android should be considered as the platform,  maybe Cordova needs a new flag, 
-engine?

e.g. cli perspective
> cordova prepare android  #uses 
> WebView of OS
> cordova prepare android -engine crosswalk   #uses Crosswalk
> cordova prepare android -engine ChromeView #uses ChromeView bundled jar

That could solve some issues with windows 8:
e.g.
> cordova prepare windows8
> cordova prepare windows8 -engine v8.1  #uses/injects 8.1  code
> cordova prepare windows8 -engine crosswalk#uses Crosswalk?

Putting this idea out there, might make the maintenance easier.
Problem for me is terminology of crosswalk as a platform, it's more like an 
engine that sits on top of the OS.

RE: tag, and accessing the plugin list

[Jonathan Bond-Caron]

On Fri Nov 15 11:29 AM, Braden Shepherdson wrote:
> I propose three things:
> 1. Punt all discussion of overhauling configuration files to the new year.
> 2. Drop my proposals above, as well as the summary Anis posted of last night's
> discussion.
> 3. Solve the immediate use-case of AppHarness wanting to know what plugins
> are installed by injecting that object into a new key attached to the array 
> of JS
> modules in cordova_plugins.js.
> 

+1

Added info about 'cordova_plugins.js' here:
https://wiki.apache.org/cordova/ConfigurationFiles

Small note to avoid confusion: the naming of the file is a bit misleading, 
'cordova_modules.js' is more appropriate. Since each plugin can have 1+ modules.

Eventually might better to rename this altogether to ~ 'cordova_meta.js(on)' 
that holds generated metadata their either native or JavaScript can read.

RE: audit of configuration

[Jonathan Bond-Caron]

On Fri Nov 15 09:28 AM, Josh Soref wrote:
> Jonathan wrote:
> > You should add:
> 
> I'll add it to the wiki if no one beats me to it.
> 
> Please feel free to edit this page or any other. If you don't have the wiki 
> edit bit,
> just send an email here with your account name and someone will give you the
> bit.

Thanks, who to ping? account 'jbondc'

> > Another use case to consider for more cordova metadata:
> 
> > cordova add language fr
> 
> I'm new here, is that actually supported? I don't recall seeing it in the
> documentation. (I'm well aware that the documentation needs work.)

It's not supported, I'll create a wiki page ;)

I'm not sure if it would fit into the globalization plugin or as a separate 
i18n plugin:
i18n plugin (language bundles)

i18n.loadData('fr_CA'); // either javascript mapping or exec() query for 
translation
i18n.getText("Hello!")
i18n.getTextCode("Hello!")

Consider default cordova error messages:
https://github.com/jbondc/cordova-plugin-media-capture/blob/6df2b2679a3d528a2691782f2b5f466abcc79d32/www/CaptureError.js#L47

It would be nice to ship with default i18n bundles that translate these 
messages. It's quite a large scope but something I have experience with.
What I'm thinking is 'add language' would add the i18n plugin + install 
language bundle for that platform.

It's something to consider for the configuration & cordova metadata.  

E.g. On windows 8, 'plugman' could insert:
package.appxmanifest
  




  

cli still has several 'gaps' to be fully useful. 

RE: audit of configuration

[Jonathan Bond-Caron]

On Thu Nov 14 06:12 PM, Josh Soref wrote:
> I've converted that into a wiki page:
> https://wiki.apache.org/cordova/ConfigurationFiles
> -

Awesome, thanks for this. You should add:

$PROJECT/platforms//www/cordova_plugins.js

- Metadata about what JavaScript modules (from plugins) should be loaded at 
runtime on this platform.
- Reads installed plugins from: $PROJECT/plugins/.json
- Written by: Plugman during prepare step
- Automatically generated

Another use case to consider for more cordova metadata:

e.g. 
> cordova add language fr

Where would metadata about the 'installed' languages go?
- Android platform = en,fr
- iOS platform = en

RE: tag, and accessing the plugin list

[Jonathan Bond-Caron]

On Thu Nov 14 01:44 PM, Andrew Grieve wrote:
> I'm going to attempt to summarize in point form:
> 
> Goal:
>  - Make available the list of installed plugins and their versions to native 
> side & JS
> side.
>  - Needed by App Harness to know whether an app is compatible with its
> bundled set of plugins.
> 
> Using cordova_plugins.js:
>  - It doesn't have the information that we need
>  - We could add the extra information, but not easily since the file exports 
> an
> array instead of an object.
>  - This file is not currently parsed by the native layer, so having the info 
> here
> would be an extra IO on start-up.
> 

Great summary :)

Is it difficult to rename ' cordova_plugins.js' to something more broad 
'cordova_meta.js', ' cordova_loader.js', 'cordova_boot.js' and using an object?
Since it's generated code, first impression is there's no BC issue other than 
doing another prepare.

Doesn't seem like there's a way to avoid the extra IO on the native side (e.g. 
cordova_meta.js). If the detailed list of installed plugins is in xml, how will 
the JS side access it?

Broader problem is there's no single cordova meta file that's shared between 
native & js. Considering that on some platforms, there's only JavaScript, 
putting the information in JSON seems like a good move. 

RE: Refactoring the CLI tests

[Jonathan Bond-Caron]

On Thu Nov 7 11:40 AM, Braden Shepherdson wrote:
> The CLI tests are bad. I propose making them better.
> 
> I propose letting the tests actually run filesystem and related calls, 
> instead of
> always mocking them out. In the simplest form, that means running them on the
> real filesystem. If that's too slow, we can investigate other alternatives, 
> like using
> a ramdisk, or using that emulated fs that runs everything in RAM inside Node.
> 

Big +1, the cli tests are failing on windows:
https://issues.apache.org/jira/browse/CB-5330

Wouldn't be caught if it was mock tests.

For the emulated 'fs', it could be a proxy pattern to a file system on RAM:

e.g. 
testfs.setRoot('Z:\cordova-test');
testfs.init();   

// init() would remap every fs function
var fs = require('fs'), map = {'mkdir': fs.mkdirSync};

fs.mkdirSync = function (path, mode) {
  return map.mkdir(testfs.getPath(path), mode);
};

// using the default fs functions during tests is remapped to a virtual root 
path
fs.mkdirSync("C:\somewhere\cordova\foo"); // chmod 
'Z:\cordova-test\C\somewhere\cordova\foo '
fs.mkdirSync("/somewhere/cordova/foo");// chmod 
'/mounted/tmpfs/somewhere/cordov/foo '

Tmpfs is great on unix, for Windows, I use:
http://www.softperfect.com/products/ramdisk/

RE: HTML 5 platform

[Jonathan Bond-Caron]

On Wed Nov 6 01:54 AM, Darryl Pogue wrote:
> On 5 November 2013 13:37, Braden Shepherdson 
> wrote:
> >
> > Why is any development here happening outside of Cordova? Most apps
> > are going to depend on Cordova APIs too deeply to get all that far
> > with the early steps in your outline.
> >
> > Braden
> 
> My approach when developing multi-platform apps is to think of the core
> cordova.js as a polyfill manager, and the plugins as polyfills for features 
> that
> might not exist yet. 
> 
> To that end, I took the firefoxos platform of cordova.js from 3.1.0 and very
> slightly modified it and saved it as a "browser" platform[1]. I put the 
> resulting
> cordova.js in my www folder so I can run it in the browser without any cordova
> prepare commands, and when I do make a build for a device, it gets overwritten
> by the platform-specific JS file.
> 

Same approach :)  There's 3 issues for that type of workflow inside Cordova:

1) No unified cordova.js for the browser

Not sure if it makes more sense as a separate 'platform', or just a file built 
from cordova-js
See: http://goo.gl/fvNkmh

2) Version control is tricky

If you use 'codova create', it's a bit unclear what part of the application 
should be under version control, only the www/ folder?
If you target 4 platforms, you have 4 versions of the app in the platforms/ 
folder.

So right now, I prefer to consider the application outside of Cordova.

 3) App layout

This is probably more specific to my case, both cli and plugman expect the 
layout of an app to be:
www/cordova.js
www/cordova_plugins.js
www/plugins

https://issues.apache.org/jira/browse/CB-4609

Would prefer that to be configurable as for example:
www/resources/js/cordova.js
www/resources/js/cordova_plugins.js
www/resources/js/plugins

Main reason is I have additional build tools (minification etc...) that expect 
this layout.

RE: HTML 5 platform

[Jonathan Bond-Caron]

On Mon Nov 4 11:00 AM, Josh Soref wrote:
> https://issues.apache.org/jira/browse/CB-2062
> 
> > Any thoughts on adding html5 as a platform?
> 
> Fil mentioned Ripple. While not endorsing it, have you tried it?
> 
> Ripple is more or less what you want. It's a JavaScript shim to which you can
> deploy. It should also include API support for sensors and other features.

I just installed Ripple as a chrome extension. 
There still seems to be something missing to test rendering differences between 
Webkit browsers & IE 10, Firefox, while using only some of the basic Cordova 
apis.

Ripple looks great for emulation but doesn't help for cross-browser/platform 
testing & debugging. 

With the workflow:
a) Develop HTML5 app
b) Test on Webkit, IE10, Firefox
c) Import into Cordova
d) Deploy on devices (Windows 8, Android, iOS, Blackberry, ...)

For (d) Eclipse, Visual Studio, Xcode, Ripple, Cordova cli, ..? 

An example: Deploy on a Windows 8 device and the CSS doesn't work (e.g. 
flexbox), debug in Visual Studio then back at step (a) to port the changes.

Merging steps (a), (b), (c) into a single 'browser/html5' platform to do 
iterative testing/debugging would be a win.

In that sense, the 'browser/html5' platform would be the smallest subset of 
features that works consistently across all platforms:
- localStorage
- XMLHttpRequest
- JavaScript only plugins / shims

HTML 5 platform

[Jonathan Bond-Caron]

I submitted this ticket a while back:
https://issues.apache.org/jira/browse/CB-2062

For rapid development, I find browsers (chrome, ie10, safari, firefox) are 
becoming good environments for testing applications.
The workflow I'd like to use is test on browser then deploy to a physical 
device for testing platform features.

Any thoughts on adding html5 as a platform?

RE: Chromeview has arrived in Android 4.4!!!!

[Jonathan Bond-Caron]

On Thu Oct 31 10:37 PM, Joe Bowser wrote:
> 
> My main fear was that only Google devices would get KitKat WebView and that
> AOSP would get nothing, similar to how AOSP apparently doesn't have a Gallery
> or a default SMS client anymore.  There are rumours that AOSP no longer has a
> dialer, but that would be batshit insane, since that would mean that it'd be 
> next
> to impossible to make phone calls on AOSP. :(
> 

Chromium will eventually get rolled into Play Services:
https://github.com/android/platform_frameworks_base/blob/kitkat-release/core/java/android/webkit/WebViewFactoryProvider.java

That seems to be confirmed:
https://code.google.com/p/chromium/issues/detail?id=113088#c100

The good or bad news is WebView will eventually auto-update independent of 
Android releases.

Still trying to figure out how it works, does anyone know where 
'com.android.webview.chromium.WebViewChromiumFactoryProvider ' comes from?
Is this from a built /system/framework/webviewchromium.jar ?

Main implementation seems to be here:
https://chromium.googlesource.com/chromium/chromium/+/trunk/android_webview/java/src/org/chromium/android_webview/AwContents.java

RE: cordova release naming -- proposal

[Jonathan Bond-Caron]

On Wed Oct 23 10:29 AM, Lisa Seacat DeLuca wrote:

> * Hockey teams (probably some issues with trademarks) 

Love this idea :)

No trademark issue as long as there's no use of logos, printing of t-shirts 
etc...:
http://tsdr.uspto.gov/#caseNumber=74109221&caseType=SERIAL_NO&searchType=statusSearch

Could start with a 'Panthers' release from the bottom-to-top:
http://www.hockey-reference.com/leagues/NHL_2013_standings.html


 

RE: replacing webviews

[Jonathan Bond-Caron]

On Tue Oct 8 11:19 AM, Jacob Robbins wrote:
> 
> This made me wonder, has there been discussion of integrating a full
> mobile
> browser codebase into Cordova and using that instead of the
> native webview?
> Mozilla sort of went this way with XUL where you
> could take their HTML engine
> and use it in a non-browser context.
> 
> Seems to me a lot of usability problems with non-native apps result from
> running them inside the same HTML engine used by the platforms' default
> mobile browser. The native browsers are moving towards features that help
> make regular websites accessible. Being a great virtual machine for
> non-native
> apps is not a high priority for them.
> 

+1000

Unfortunately, my understanding is App Store rules requires use of UIWebView so 
don't think cross-platform is feasible

But having this option on Android would be huge (same chrome view on Android 
2.x+), I'd pay for that option

RE: config.xml discussion, we need to talk

[Jonathan Bond-Caron]

On Thu Sep 26 11:32 AM, Carlos Santana wrote:
> Branden,
>"On Android, it's really easy to load XML files from res/xml/foo.xml, so 
> that's
> where we put it."
> 
> Easy for who?
> I think is difficult for web developer to not find it in www/config.xml and 
> start
> searching for it
> 

But config.xml has nothing to do with an HTML5 application, it's a cordova 
specific thing (hybrid app config).

It's nice to have it align with the w3c spec for widgets but we're talking 
about 2 different things:
- Hybrid application configuration (which may have enable platform specific 
features)
- HTML5 application configuration (~ w3c widget spec which I'm personally not a 
fan)
The scope of the HTML5 app configuration IMHO is outside of cordova and 
certainly up for debate.

RE: config.xml discussion, we need to talk

[Jonathan Bond-Caron]

On Thu Sep 26 10:18 AM, Braden Shepherdson wrote:
> I am strongly opposed to splitting into one file per platform. We want to 
> support
>  tags in config.xml, which will allow platform-specific content 
> within
> the single config.xml.
> 

+1, a single configuration file not in the www/ folder

RE: plugman / cli verbose by default?

[Jonathan Bond-Caron]

On Wed Sep 4 04:38 PM, Andrew Grieve wrote:
> 
> You can always use --quiet if you pipe our command and have it not output.
> Am I missing something about your use-case?
> 
> We have a practical problem right now in that we get a lot of bad bug reports
> where we need to tell users to re-run with --verbose. Almost every day in IRC,
> someone gets told to re-run with --verbose.
> 

--quiet would be useful

I think part of the problem is cli should output more useful information and 
there's missing 'log levels'.

> plugin add foo
Adding foo from http://github.com/bar/foo.git
foo installed!

Somewhat related, 
require(../plugman).emit('log', 'something');

Could be changed to 
Logger.log("message"); // default would be "info" level
Logger.log("doing advanced stuff", "verbose");
Logger.log("Something bad happened", "error");

RE: cli plugins 'alias'?

[Jonathan Bond-Caron]

On Tue Sep 3 01:09 PM, Brian LeRoux wrote:
> Or you could create cordova-plugin-core, cordova-plugin-chromeos, and
> cordova-plugin-phonegap repos, with a plugin.xml that have the
> dependencies
> you describe to achieve the same result.
> 
> As the other guys mentoin, there's many ways to do this now without
> adding a
> new feature which is the most pragmatic approach. (This will
> be dramatically
> easier and more obvious once
> http://plugins.cordova.io ships at the end of hte
> month.)
> 

Sounds good to wait and see, might be ok to just distinguish required vs. 
non-required

https://github.com/jbondc/cordova-labs.git"; subdir="cordova-plugin-echo" 
required="false" /> 

RE: What's your daily workflow for cordova development?

[Jonathan Bond-Caron]

On Mon Sep 2 07:34 PM, Brian LeRoux wrote:
> Here's a shot. Ideal flow tomorrow might be to generate a plugin called, lets 
> say,
> "Echo" that matches something we'd find in our docs, automate add/remove
> with some sort of watch command. That way ppl are writing to the plugin spec
> from the beginning instead of refactoring a plugin out of a native project.
> 
> Thoughts?
> 

Two new features could be useful from cli:
a) Create an initial plugin from a template
cordova plugin create [path] [name]

e.g. 
> cordova plugin create F:/GitHub/MyPlugin MyPlugin

b)  Update all plugins from a cordova application
cordova plugins update

e.g.
> cordova create F:/CordovaApp
> cd F:/CordovaApp
> cordova plugin add F:/GitHub/MyPlugin
> cordova plugins update

The implementation is likely tricky, how to detect plugin modification? Version 
check?
I image it would remove & install the new plugin.

> cordova plugins update -local

Could  be useful to force the removal and reinstall of only local plugins (from 
a filesystem path) / under development... 

I haven't gotten around to running .spec tests but something simple as:
c) Running tests within plugin directory
cd F:/GitHub/MyPlugin
cordova plugin test

[Test #1] Passed
[Test #2] Failed: Reference error foo doesn't not exist

Would be very useful.

cli plugins 'alias'?

[Jonathan Bond-Caron]

Setting up the mobile spec app was tedious since I didn't know the dependencies.

I wrote a small patch that allows to pull a plugin from a git subdirectory
e.g. cordova plugin add 
https://github.com/jbondc/cordova-labs?subdir=cordova-deps-mobile-spec
https://issues.apache.org/jira/browse/CB-4715

It got me thinking there might an opportunity to make this less tedious with an 
'alias'

e.g. cordova plugin add @cordova-test

The @ symbol signals an 'alias' (cordova-test) that cli would expand to 
"https://.../cordova-plugin-battery-status https://.../cordova-plugin-device 
etc..."
The list of plugins simply gets passed to plugman.

A couple of 'core' aliases could make it easier to get started with cordova, 
e.g.
cordova plugin add @cordova-common
cordova plugin add @cordova-test
cordova plugin rm @cordova-test

Could also be called packaged / collection /  grouped plugins.

Thoughts?

RE: Module name & plugin id

[Jonathan Bond-Caron]

> Is there any reason why the 'module name' isn't the plugin id (when loading
> JavaScript):
> https://github.com/apache/cordova-plugman/blob/master/src/prepare.js#L149
> 

In case it helps someone, plugins can have multiple js-module declarations:





This name is appended to the plugin id.

Note: the meaning of "clobbers target" isn't obvious, a suggestion for a more 
obvious name could be:

RE: Cordova Gesture plugin

[Jonathan Bond-Caron]

On Sun Aug 18 10:25 PM, Ian Clelland wrote:
>
>   https://issues.apache.org/jira/browse/CB-4609
> 
> Is this preventing any plugins from working at all, or is it just
> something about your new plugin?

It seems like two issues in 3.0 release:
1) Issue with Windows path
2) Plugin loading works (cordova_plugins.js) but fails somewhere on Android 
with:
08-19 09:53:26.173: D/chromium(1708): Unknown chromium error: -6

As a first user experience, it would seem simpler if all the plugins were 
concat/bundled into 'cordova_plugins.js' 
e.g. cordova prepare android (would concat javascript into 'cordova_plugins.js')

The advanced use case(s) could support the dynamic loading of JavaScript 
plugins.

> 
> The only thing that I can see that's a bit odd in your plugin is the
> android-feature line in plugin.xml:
> 
> 
> 
> That value, I think, should end with the class that extends
> CordovaPlugin, namely "Gesture".
> 

Thanks, fixed

> 
> 
>   An important note for the plugin to be viable, 2 methods would need to
> be added to 'CordovaWebView':
>   disableTouchEvents()
>   registerGestureHandler()
> 
> I'm actually working on a patch that should make it easier for an
> application to provide a custom WebView class that extends CordovaWebView,
> but I'm not sure how feasible it is for plugins to do the same. We might
> have to look at other ways of overriding methods like those (because I'm
> sure that they won't be the last ones).
> 

That would be really useful, especially adding methods & properties to the 
webview.

For overriding methods, it adds some complexity that may not be worth it. 
If 2+ plugins override the same methods, there's potential plugin 
incompatibility.
It may reduce the reliability of 'core' cordova by causing odd bugs that are 
hard to track.

Maybe some specific parts of the webview could be extended / modified depending 
on what plugins need to do.

Cordova Gesture plugin

[Jonathan Bond-Caron]

I participated at a #hackmtl event in Montreal and thought it would be a good 
opportunity to try building a 'Cordova Gesture' plugin:
https://github.com/jbondc/cordova-plugin-gesture

My first time using 3.0.0 went very smoothly, the simple command line tools are 
great.

Unfortunately I didn't complete the 'proof-of-concept' since I got stuck where 
the javascript plugin seems to load but fails:
https://issues.apache.org/jira/browse/CB-4609

An important note for the plugin to be viable, 2 methods would need to be added 
to 'CordovaWebView':
disableTouchEvents()
registerGestureHandler()

The code works by intercepting the 'onTouchEvent', tries to detect a gesture 
and pass it directly to the DOM:
https://github.com/jbondc/mtlhack-PhoneGap-gesture/blob/master/cordova/platforms/android/src/org/hackmtl/phonegap/gestures/TestWebView.java

Feel free to fork away and provide feedback,
Cheers, Jon

getPicture() and error callback (CaptureError)

[Jonathan Bond-Caron]

I'm developing an app for iOS, Android, Windows 8, and noticed the getPicture() 
api is very inconsistent on the errorCallback:
https://issues.apache.org/jira/browse/CB-4071
http://docs.phonegap.com/en/2.9.0/cordova_camera_camera.md.html#camera.getPicture

Would the api in 3.0 return a CaptureError object? It would be more practical 
to wrap the error in an object instead of a string.

[jira] [Created] (CB-2062) HTML5 platform

[Jonathan Bond-Caron (JIRA)]

Jonathan Bond-Caron created CB-2062:
---

 Summary: HTML5 platform
 Key: CB-2062
 URL: https://issues.apache.org/jira/browse/CB-2062
 Project: Apache Cordova
  Issue Type: New Feature
  Components: CordovaJS
Affects Versions: 2.2.0
 Environment: Any HTML5 browser (IE10, Chrome, Safari)
Reporter: Jonathan Bond-Caron
Assignee: Filip Maj
Priority: Minor
 Fix For: Master


I currently use the Cordova 'Android JavaScript' to do testing in the browser. 
Chrome and Safari work nicely since they are both based on WebKit.

It would be nice to use HTML5 javascript that is expected to work in any HTML5 
browser. 

There are HTML5 features like getUserMedia() to take a picture within the 
browser.
Here’s some rough code: 
http://pastebin.com/zKDpmV0d

There's still a long way to go from HTML5 to be a 'platform', but it would be 
useful for testing/debugging in the short term.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CB-753) ER: API to query if device has a camera

[Jonathan Bond-Caron (JIRA)]

[ 
https://issues.apache.org/jira/browse/CB-753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13532252#comment-13532252
 ] 

Jonathan Bond-Caron commented on CB-753:


Small clarification, the purpose of device.has() or device.hasCapability() 
would be to always return a boolean value:

window.device.has = function(feature) { return this.capabilities[feature]) ? 
true : false }


Plugins could extend window.device.capabilities with additional information 
about the device.

> ER: API to query if device has a camera
> ---
>
> Key: CB-753
> URL: https://issues.apache.org/jira/browse/CB-753
> Project: Apache Cordova
>  Issue Type: New Feature
>Affects Versions: 1.7.0
>Reporter: Jean-Pierre
>Priority: Minor
>
> Cordova does not offer any API to query the device for its capabilities, so 
> one cannot know if it has a camera with which to take a picture without 
> attempting to take a picture, falling through the error handler and then 
> hard-match the error code -- a pretty poor user experience. i have seen some 
> suggestion to check device.camera, but a device may still have a library to 
> pull an image from while not having a camera, so that isn't likely helpful. 
> there isn't even any way to find the specific hardware revision to match off 
> that.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CB-753) ER: API to query if device has a camera

[Jonathan Bond-Caron (JIRA)]

[ 
https://issues.apache.org/jira/browse/CB-753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13532247#comment-13532247
 ] 

Jonathan Bond-Caron commented on CB-753:


Thanks, some more thoughts:

I image that window.device.capabilities = {} would be initially an empty object?

Then the camera plugin when/if loaded would set:

window.device.capabilities.camera = {front: true, back: false};
window.device.capabilities.frontCamera = true;
window.device.capabilities.backCamera = true;

I'd also propose a 'shortcut' (sugar function): window.device.has('camera') , 
window.device.has('frontCamera')



> ER: API to query if device has a camera
> ---
>
> Key: CB-753
> URL: https://issues.apache.org/jira/browse/CB-753
> Project: Apache Cordova
>  Issue Type: New Feature
>Affects Versions: 1.7.0
>Reporter: Jean-Pierre
>Priority: Minor
>
> Cordova does not offer any API to query the device for its capabilities, so 
> one cannot know if it has a camera with which to take a picture without 
> attempting to take a picture, falling through the error handler and then 
> hard-match the error code -- a pretty poor user experience. i have seen some 
> suggestion to check device.camera, but a device may still have a library to 
> pull an image from while not having a camera, so that isn't likely helpful. 
> there isn't even any way to find the specific hardware revision to match off 
> that.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CB-753) ER: API to query if device has a camera

[Jonathan Bond-Caron (JIRA)]

[ 
https://issues.apache.org/jira/browse/CB-753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13531157#comment-13531157
 ] 

Jonathan Bond-Caron commented on CB-753:


Agree that it would be nice for Cordova to fill this 'gap', native platforms 
allow to check this:

http://stackoverflow.com/questions/7736973/check-camera-existence-in-ios-pho
negap
http://stackoverflow.com/questions/12976725/checking-for-camera-access-in-ph
onegap?lq=1


If could likely be added int two ways:
- navigator.camera.isAvailable()
- device.hasFeature('camera');


> ER: API to query if device has a camera
> ---
>
> Key: CB-753
> URL: https://issues.apache.org/jira/browse/CB-753
> Project: Apache Cordova
>  Issue Type: New Feature
>Affects Versions: 1.7.0
>Reporter: Jean-Pierre
>Priority: Minor
>
> Cordova does not offer any API to query the device for its capabilities, so 
> one cannot know if it has a camera with which to take a picture without 
> attempting to take a picture, falling through the error handler and then 
> hard-match the error code -- a pretty poor user experience. i have seen some 
> suggestion to check device.camera, but a device may still have a library to 
> pull an image from while not having a camera, so that isn't likely helpful. 
> there isn't even any way to find the specific hardware revision to match off 
> that.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

HTML5 PLatform

[Jonathan Bond-Caron]

-  Are there any plans to have an 'HTML5' platform/release?

I use the Cordova 'Android JavaScript' to do testing in the browser. Chrome
and Safari work nicely since they are both based on WebKit.

 

What I'd like really like is to use HTML5 features like
getUserMedia() to take a picture within the browser.

Here's some rough code I'm using:
http://pastebin.com/zKDpmV0d

 

-  Does anyone know a way to detect if a camera exists?

http://stackoverflow.com/questions/7736973/check-camera-existence-in-ios-pho
negap

http://stackoverflow.com/questions/12976725/checking-for-camera-access-in-ph
onegap?lq=1

 

Would be nice if Cordova could fill this 'gap', native platforms allow to
check this.

 



 

 

 

 

RE: Android WebView

[Jonathan Bond-Caron]

Ya calling invalidate() right after onDraw() is wrong. 

My experience is only with ICS on JB, but invalidate() will only affect
native/java (e.g. an android rectangle EditText on top of an HTML input).
It has no impact on the HTML/CSS webkit engine.

It's actually the other way around, the webkit engine (c++) calls
viewInvalidate() in c++ when in the DOM  cursor/scrolling etc.. events
happen, this calls invalidate() in java.
The purpose of invalidate() is to force the re-render of *java* components
painted on the canvas.

> -Original Message-
> From: Joe Bowser [mailto:bows...@gmail.com]
> Sent: November 22, 2012 4:51 PM
> To: dev
> Subject: Re: Android WebView
> 
> OK, so what's the downside of constantly forcing the view to be redrawn
> over and over again?  That's the thing that I would be most concerned
> about.
> >
> >
> > On Thu, Nov 22, 2012 at 3:55 PM, Simon MacDonald
> > wrote:
> >
> >> Hey all,
> >>
> >> Anything we can use from this SO answer to make the webview faster?
> >>
> >>
> >> http://stackoverflow.com/questions/13500452/android-webview-renders-
> b
> >> lank-white-view-doesnt-update-on-css-changes-or-html

RE: [Android] Question about onPause vs pauseTimers()

[Jonathan Bond-Caron]

On Tue Nov 6 01:41 PM, Joe Bowser wrote:
> Hey
> 
> Apparently the pause and resume bug still exists, and I think it's 
> caused by the pause and resume timers not being executed properly.
> I'm looking at the Private API to see what this actually does so I can 
> try and write a JUnit test for this, but I'm not clear what the 
> difference between EventHub.ON_PAUSE and EventHub.PAUSE_TIMERS is 
> exactly?  Does anyone who is more familiar with the WebKit side of 
> things know? Do we need to pause the timers if we're actually calling 
> onPause on the WebViewClassic view?
> 
> Any ideas?

Hi Joe, here are some of my notes. The only thing I understand about
resumeTimers() is there's a potential 'refcount' bug:
http://code.google.com/p/google-mobile-dev/issues/detail?id=9

-- Pause WebViewCore

Create an illusion of pausing the webView by slowing down of DOM timers
(less cpu usage / lower battery usage)
Also disables geolocation & sends 'pause' event (kPause_ANPLifecycleAction)
to webkit plugins (e.g. flash).

JAVA:
onPause()  EventHub.ON_PAUSE
onResume() EventHub.ON_RESUME

CPP:
https://github.com/android/platform_external_webkit/blob/master/Source/WebKi
t/android/jni/WebViewCore.cpp#L4795

The interesting part is that setMinDOMTimerInterval() changes TIMER to 1s
(paused) from 0.04s (resume)  
https://bugs.webkit.org/show_bug.cgi?id=45362

viewImpl->sendPluginEvent() sends the 'pause' event to webkit plugins and
then back to JAVA (via plugin bindings).
http://www.slideshare.net/seiyonl/android-webkit-browser-plugin


-- Pause WebView timers

Tries to close network connections and temporarily disables javascript
timers?

resumeTimers() EventHub.RESUME_TIMERS
pauseTimers()  EventHub.PAUSE_TIMERS

Pausing changes the *thread* priority to THREAD_PRIORITY_BACKGROUND.

Don't understand what 'JWebCoreJavaBridge' does with timers and it looks
buggy.

http://code.google.com/p/google-mobile-dev/issues/detail?id=9
http://blog.csdn.net/elfylin/article/details/7072406