Re: Better discussion forum?

[Terence M. Bandoian]

+1


On 7/31/2018 12:57 PM, Darryl Pogue wrote:

To expand on this a bit more, annoying as the mailing list might be, I
think the project would be better for having a more active mailing
list and not having discussions spread across lists and multiple
GitHub repos and Slack and JIRA and various Google Docs. I'm
definitely guilty of adding to that spread of information because it's
convenient, but it does impose a bit of a barrier for participation.

The idea is that all decisions have to happen on the mailing list,
because this is the one place that all Cordova devs are supposed to be
subscribed. This is the one place that everyone can watch to keep on
top of what's happening in the project.

We've been *terrible* at that over the years, and it's made it hard to
provide feedback on changes because I didn't know they were happening.
Roadmaps were discussed in face-to-face meetings or video calls and
not brought back to the list for review, and it was hard to find out
what was being worked on short of stumbling upon tasks in JIRA or
watching peoples' personal GitHub forks.
I don't say that to put blame on anyone, because they were doing what
they'd always done and there wasn't (and isn't) a culture of bringing
things back to the list. But I do say it because I think we can
improve and I think it's worthwhile to try to use the list as the
place for discussions so that there's a recorded history of decisions.

I know plaintext email doesn't offer nearly as much in the way of
formatting, so at the very least it would be good to send a link to
proposal documents to the list, and ask for feedback to be posted in
that thread.

On Tue, Jul 31, 2018 at 10:32 AM Darryl Pogue  wrote:

Apache Software Foundation projects use mailing lists for communication.
It is The Apache Way.

See http://apache.org/foundation/how-it-works.html#communication

On Tue, Jul 31, 2018 at 10:10 AM Chris Brody  wrote:

I would really love to see a better discussion forum for ideas. I
think the mail list is not so handy for forums with cross-referencing
and cordova-discuss proved to be a failure. npm.community seems to
have nailed it, though it may have been meant to solve another
problem. Any comments?

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org




-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: Stepping Back

[Terence M. Bandoian]

Sorry to see you leave the project.  You provided strong technical 
leadership and I think are one of the main reasons Cordova is usable.  I 
hope you'll at least keep a watch from a distance and be willing to 
provide guidance and insight from time to time.  Thanks for all your 
efforts.


-Terence Bandoian


On 6/21/2018 5:33 AM, Jan Piotrowski wrote:

That's a real shame, hope you landed in a interesting new area.
Thanks for your work over the years!

J

2018-06-20 20:22 GMT+02:00 Joe Bowser :

Hey

As many people may be aware, I've moved on to another team at Adobe, so I
will no longer be able to be the primary maintainer of Cordova for Android,
and I won't be available to review any PRs in the future.  It's been an
interesting decade of development, and I'm thankful for all the people who
chose to try and build applications with PhoneGap/Cordova, even if it
wasn't the right choice for them.

Thanks

Joe Bowser



-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: [DISCUSS] Android & iOS release

[Terence M. Bandoian]

Is this related to the difference between  targets in 
config.xml and plugin.xml?


In config.xml,  target attribute values are relative to 
the base platform directory.  In plugin.xml, they are relative to 
app/src/main in the base platform directory.


Would it be useful to document this?

-Terence


On 4/18/2018 10:28 AM, Joe Bowser wrote:

Looks good.  I'll do a quick sanity check later today, but it should be
fine.

On Wed, Apr 18, 2018 at 5:26 AM, julio cesar sanchez :


Joe or myself don't currently have the time to fix this problem and
probably won't for the foreseeable future. Plugin maintainers can send

PRs

to cordova-android adding their mapping if they want or update their
plugins.

But I'd like to get this release out because of the bug fixes that have
landed and because the release train should keep rolling. A future

release

can happen with those fixes once PRs come in

On Tue, Apr 17, 2018 at 2:59 PM, Joe Bowser  wrote:


On Tue, Apr 17, 2018 at 2:54 PM, julio cesar sanchez <
jcesarmob...@gmail.com

wrote:
Yeah, but our plugins work because we have put some code to copy our

files

to a new location instead of updating the paths in the plugins'

plugin.xml.

This is handled for what our plugins need, but not for all the

possible

cases, so I don't think it's ok to make a patch to just make our

plugins

work but don't do the same for other allowed files. If we didn't

update

the

core plugins for the new path we shouldn't ask users to do it in

their

plugins.



Fair, we should really be updating all our plugins and figuring out how

to

remove the patch.  The last thing I want to see is this code growing

like

a cancer, which it very well could.  I don't think we should be

delaying

the release because of third party plugins not being able to be

installed.



Also there is the problem I told you about the false positive making

it

think it's an Eclipse project and making our plugins fail to install

if

they are installed after a plugin with the previos problem.



Yeah, that's a pretty major failure that we never saw when we were

testing

7.0.  I don't think this should delay the release either unless a PR
arrives that fixes this.




2018-04-17 23:30 GMT+02:00 Joe Bowser :


I disagree.  We have our core plugins installing and uninstalling

without

issue currently, and we can't babysit everyone with their third

party

plugins.  The community needs to come up with a plan on deprecating

the

old

project structure and communicating that to the third party plugin
maintainers.


On Tue, Apr 17, 2018 at 2:28 PM, julio cesar sanchez <
jcesarmob...@gmail.com

wrote:
Before doing an Android release we should fix the problems with

plugins

installs, people is not updating because of it

2018-04-17 3:31 GMT+02:00 gandhi rajan 

Re: Fixed Locations for Build Artifacts?

[Terence M. Bandoian]

Ohhh.  I think I get it now.  My understanding is that the directory 
structure expected by Android Studio changes regularly and Cordova has 
no choice but to change along with it.  However, Visual Studio expects 
Android debug APKs to be specifically named and located in order to 
start Android debug sessions.  This is convenient if you're developing 
for Windows and Android because a single IDE can be used for both 
platforms and the Cordova project source files are directly accessible 
in the IDE.


The after-build script I posted in issue CB-13932 
(https://issues.apache.org/jira/browse/CB-13932) resolves the Android 
debug APK naming/location problem in Visual Studio but I'm wondering if 
there are any other tools with similar build artifact name/location 
expectations.  If so, Cordova could potentially insulate those tools 
from breakages by incorporating something as simple as the above 
after-build script into the build processes.


-Terence


On 3/11/2018 11:16 PM, Joe Bowser wrote:

I don't see this code as being worth maintaining, since Google often
changes build tools versions and we barely have the resources now to play
catch up.

On Mar. 11, 2018 8:05 p.m., "Terence M. Bandoian" <tere...@tmbsw.com> wrote:


Would it make sense to copy build artifacts to fixed locations, with fixed
names, and to publicize those locations and names for the use of downstream
tools?  This would help avoid unnecessary breakages when the build tools
used or the project structures generated by Cordova are modified.

-Terence Bandoian


-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org





-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: Fixed Locations for Build Artifacts?

[Terence M. Bandoian]

Ohhh.  I think I get it now.  My understanding is that the directory 
structure expected by Android Studio changes regularly and Cordova has 
no choice but to change along with it.  However, Visual Studio expects 
Android debug APKs to be specifically named and located in order to 
start Android debug sessions.  This is convenient if you're developing 
for Windows and Android because a single IDE can be used for both 
platforms and the Cordova project source files are directly accessible 
in the IDE.


The after-build script I posted in issue CB-13932 
(https://issues.apache.org/jira/browse/CB-13932) resolves the Android 
debug APK naming/location problem in Visual Studio but I'm wondering if 
there are any other tools with similar build artifact name/location 
expectations.  If so, Cordova could potentially insulate those tools 
from breakages by incorporating something as simple as the above 
after-build script into the build processes.


-Terence


On 3/11/2018 11:16 PM, Joe Bowser wrote:

I don't see this code as being worth maintaining, since Google often
changes build tools versions and we barely have the resources now to play
catch up.

On Mar. 11, 2018 8:05 p.m., "Terence M. Bandoian" <tere...@tmbsw.com> wrote:


Would it make sense to copy build artifacts to fixed locations, with fixed
names, and to publicize those locations and names for the use of downstream
tools?  This would help avoid unnecessary breakages when the build tools
used or the project structures generated by Cordova are modified.

-Terence Bandoian


-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org





-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Fixed Locations for Build Artifacts?

[Terence M. Bandoian]

Would it make sense to copy build artifacts to fixed locations, with 
fixed names, and to publicize those locations and names for the use of 
downstream tools?  This would help avoid unnecessary breakages when the 
build tools used or the project structures generated by Cordova are 
modified.


-Terence Bandoian


-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: [DISCUSS] Cordova-Windows 6.0.0

[Terence M. Bandoian]

There is also:

   

It apparently has the same meaning as Windows.Universal-MinVersion but 
sets the value in the jsproj file vs the appxmanifest file.  Is there 
any reason a user would want different values in those two files?


-Terence


On 2/9/2018 7:01 PM, Terence M. Bandoian wrote:
I'm not sure they're what you're looking for but there are three 
version-related Windows preferences that seem to be supported in 
config.xml:



value="10.0.14393.0" />
value="10.0.16299.125" />


Does one or more of these resolve this?

-Terence



On 2/9/2018 6:41 PM, Jesse wrote:

Created an issue for making this configurable. CB-13862


@purplecabbage
risingj.com

On Fri, Feb 9, 2018 at 4:23 PM, Jesse <purplecabb...@gmail.com> wrote:

All correct and I agree, except we do need to update 
TargetPlatformVersion

pr here: https://github.com/apache/cordova-windows/pull/250
Please test this pr on your windows machine and make sure you can 
create
and run a new cordova-windows project without having to modify the 
jsproj

file manually.


@purplecabbage
risingj.com

On Fri, Feb 9, 2018 at 3:37 PM, Jan Piotrowski <piotrow...@gmail.com>
wrote:


Ok, so this version can be compared to the iOS or Android API version?
Then it defintely makes sense to do some work to make this
configurable in a better way in the future.
Jesse, do you want to create the issue? You seem to have a specific
idea already.

To recap:
- We think the test failure is a problem only happening on AppVeyor
and should not affect actual users
- We are ok with starting a 6.0.0 release with the current `master`
state with this one failing test on AppVeyor
- We "pledge" to further look into it and release 6.0.1 or 6.1.0 if we
indeed find the solution

Agree?

If so, I will start the release process until Monday.

J

PS: I will contact AppVeyor to find out if they can maybe help -
blocked file, maybe because of some other running process?




2018-02-09 23:13 GMT+01:00 Jesse <purplecabb...@gmail.com>:

There is a list of the timeline for all relevant versions here:
https://docs.microsoft.com/en-us/windows/uwp/updates-and-ver

sions/choose-a-uwp-version

There are 2 important values at play:
Target Version : this should probably be the most recent release we
support, probably 16299
Minimum Version : this should be as far back as we can go ...
probably 10586

Ultimately we will need to add a method to configure these values via
config.xml preferences, but I don't think we should wait for that to

happen.
Changing these values on my windows machine meant all the tests 
passed,

I

had failing tests using master as-is.

The failing test on appveyor is something different related to

environment
I believe.  Making these same changes that worked on my machine 
did not

fix

the fail on appveyor.

I think we should go ahead with the 6.0.0 release, and plan to do a

patch

release in the near future when we work out the details of a

configurable

target/minimum version.





@purplecabbage
risingj.com

On Fri, Feb 9, 2018 at 1:14 PM, Chris Brody <chris.br...@gmail.com>

wrote:
On Feb 9, 2018 3:15 PM, "Jan Piotrowski" <piotrow...@gmail.com> 
wrote:


Jesse, they do - but I am not sure why. Problem is I don't fully
understand what is going on there... which is why I am hesitant to
just ignore it.



Makes sense to me


Chris, where and how exactly does one install the "target platform

SDK"?



Visual Studio 2017 comes with an installer program. It is 
possible to
install an older platform SDK version but I do not want to do 
this on

my

PC.


What happens if you do not change the `TargetPlatformVersion` 
manually

but have only that one installed?



I would get an error message that the needed platform SDK version 
does

not

exist.


VS2017 did not exist at the time of the last release (or at least
nobody cared) so CI didn't use it to test.



Makes sense


This should have been added
earlier, but I only added it 3 weeks ago with
https://github.com/apache/cordova-windows/commit/
f5f4b21ad2c030ff61550bc947dca196c570f0ad
- which then showed this bug.



Good work on your part


(If any of the other failures that were
then fixes also were caused only by VS2017 I can not say
unfortunately)



It would be nice to investigate and test this, if anyone has the 
time

for

it.


-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org







-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: [DISCUSS] Cordova-Windows 6.0.0

[Terence M. Bandoian]

I'm not sure they're what you're looking for but there are three 
version-related Windows preferences that seem to be supported in config.xml:



value="10.0.14393.0" />
value="10.0.16299.125" />


Does one or more of these resolve this?

-Terence



On 2/9/2018 6:41 PM, Jesse wrote:

Created an issue for making this configurable. CB-13862


@purplecabbage
risingj.com

On Fri, Feb 9, 2018 at 4:23 PM, Jesse  wrote:


All correct and I agree, except we do need to update TargetPlatformVersion
pr here: https://github.com/apache/cordova-windows/pull/250
Please test this pr on your windows machine and make sure you can create
and run a new cordova-windows project without having to modify the jsproj
file manually.


@purplecabbage
risingj.com

On Fri, Feb 9, 2018 at 3:37 PM, Jan Piotrowski 
wrote:


Ok, so this version can be compared to the iOS or Android API version?
Then it defintely makes sense to do some work to make this
configurable in a better way in the future.
Jesse, do you want to create the issue? You seem to have a specific
idea already.

To recap:
- We think the test failure is a problem only happening on AppVeyor
and should not affect actual users
- We are ok with starting a 6.0.0 release with the current `master`
state with this one failing test on AppVeyor
- We "pledge" to further look into it and release 6.0.1 or 6.1.0 if we
indeed find the solution

Agree?

If so, I will start the release process until Monday.

J

PS: I will contact AppVeyor to find out if they can maybe help -
blocked file, maybe because of some other running process?




2018-02-09 23:13 GMT+01:00 Jesse :

There is a list of the timeline for all relevant versions here:
https://docs.microsoft.com/en-us/windows/uwp/updates-and-ver

sions/choose-a-uwp-version

There are 2 important values at play:
Target Version : this should probably be the most recent release we
support, probably 16299
Minimum Version : this should be as far back as we can go ...
probably 10586

Ultimately we will need to add a method to configure these values via
config.xml preferences, but I don't think we should wait for that to

happen.

Changing these values on my windows machine meant all the tests passed,

I

had failing tests using master as-is.

The failing test on appveyor is something different related to

environment

I believe.  Making these same changes that worked on my machine did not

fix

the fail on appveyor.

I think we should go ahead with the 6.0.0 release, and plan to do a

patch

release in the near future when we work out the details of a

configurable

target/minimum version.





@purplecabbage
risingj.com

On Fri, Feb 9, 2018 at 1:14 PM, Chris Brody 

wrote:

On Feb 9, 2018 3:15 PM, "Jan Piotrowski"  wrote:

Jesse, they do - but I am not sure why. Problem is I don't fully
understand what is going on there... which is why I am hesitant to
just ignore it.



Makes sense to me


Chris, where and how exactly does one install the "target platform

SDK"?



Visual Studio 2017 comes with an installer program. It is possible to
install an older platform SDK version but I do not want to do this on

my

PC.


What happens if you do not change the `TargetPlatformVersion` manually
but have only that one installed?



I would get an error message that the needed platform SDK version does

not

exist.


VS2017 did not exist at the time of the last release (or at least
nobody cared) so CI didn't use it to test.



Makes sense


This should have been added
earlier, but I only added it 3 weeks ago with
https://github.com/apache/cordova-windows/commit/
f5f4b21ad2c030ff61550bc947dca196c570f0ad
- which then showed this bug.



Good work on your part


(If any of the other failures that were
then fixes also were caused only by VS2017 I can not say
unfortunately)



It would be nice to investigate and test this, if anyone has the time

for

it.


-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org





-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: Transparent Splash Screen Background - Windows 10

[Terence M. Bandoian]

So should we go ahead and merge the PR before it becomes conflicted?

-Terence


On 1/11/2018 5:58 AM, Jan Piotrowski wrote:

Sounds like a very useful change that will improve Cordova apps on Windows.
+1

2018-01-11 11:56 GMT+01:00 Terence M. Bandoian <tere...@tmbsw.com>:

Julio suggested I bring this up for discussion so... related to:

 CB-13641 - https://issues.apache.org/jira/browse/CB-13641
 and https://github.com/apache/cordova-windows/pull/245

I'd like to find out if there is any support for or objections to allowing
transparent splash screen backgrounds on Windows.

As you know, Cordova apps targeting Windows 10 execute on desktops and
laptops in addition to tablets.  In that environment, some apps - the
Settings app, for example - use the user-selected accent color for the
splash background as well as the title bar background. Following that
convention in some cases results in a more aesthetically pleasing startup
than with a fixed color.  And, using 'transparent' as the splash background
color value causes exactly that to take place.

In the current splash screen implementation for Windows, both the title bar
background and the window background are filled with the splash background
color at startup.  Then, when the splash page is hidden, the title bar
reverts to the user-selected accent color and the window to the app
background which, depending on the colors in use, may not be a very
appealing transition.

In my case, I found using the accent color as the background much more
satisfying which is why I went ahead and created the PR.  Other developers
may find it useful as well.  And for those that don't, an RGB color can
still be supplied.

-Terence Bandoian


-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org




-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Transparent Splash Screen Background - Windows 10

[Terence M. Bandoian]

Julio suggested I bring this up for discussion so... related to:

CB-13641 - https://issues.apache.org/jira/browse/CB-13641
and https://github.com/apache/cordova-windows/pull/245

I'd like to find out if there is any support for or objections to 
allowing transparent splash screen backgrounds on Windows.


As you know, Cordova apps targeting Windows 10 execute on desktops and 
laptops in addition to tablets.  In that environment, some apps - the 
Settings app, for example - use the user-selected accent color for the 
splash background as well as the title bar background. Following that 
convention in some cases results in a more aesthetically pleasing 
startup than with a fixed color.  And, using 'transparent' as the splash 
background color value causes exactly that to take place.


In the current splash screen implementation for Windows, both the title 
bar background and the window background are filled with the splash 
background color at startup.  Then, when the splash page is hidden, the 
title bar reverts to the user-selected accent color and the window to 
the app background which, depending on the colors in use, may not be a 
very appealing transition.


In my case, I found using the accent color as the background much more 
satisfying which is why I went ahead and created the PR.  Other 
developers may find it useful as well.  And for those that don't, an RGB 
color can still be supplied.


-Terence Bandoian


-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

[DISCUSS] Plugins release

[Terence M. Bandoian]

Does the splash screen plugin include the Windows splash screen or is 
that completely in cordova-windows?  I recently submitted a pull request 
(CB-13641) to support transparent splash screen backgrounds on Windows 
and it would be nice to be able to get that from the official 
repository.  It's been reviewed but I'm not sure it's been merged.


-Terence Bandoian


On 12/27/2017 12:23 PM, Simon MacDonald wrote:

Hey all,

Any issues with doing a patch release for the plugins? All of the major
version bumps we did for:

 cordova-plugin-battery-status: 2.0.0 (8f1872cd45)
 cordova-plugin-camera: 4.0.0 (4ae0de1c5e)
 cordova-plugin-contacts: 3.0.1 (cfdffed461)
 cordova-plugin-device: 2.0.0 (753f956da4)
 cordova-plugin-dialogs: 2.0.0 (839eb34d06)
 cordova-plugin-file: 6.0.0 (957e1dcb22)
 cordova-plugin-geolocation: 4.0.0 (0f5868057f)
 cordova-plugin-globalization: 1.0.9 (a7b978f4a5)
 cordova-plugin-inappbrowser: 2.0.0 (d85991accb)
 cordova-plugin-media: 5.0.0 (4a7b55cceb)
 cordova-plugin-media-capture: 3.0.0 (52cfcf1052)
 cordova-plugin-network-information: 2.0.0 (2cfc366c2a)
 cordova-plugin-splashscreen: 5.0.0 (36bf91c9e8)
 cordova-plugin-statusbar: 2.4.0 (caf2ae6605)
 cordova-plugin-screen-orientation: 3.0.0 (044e8cc728)
 cordova-plugin-vibration: 3.0.0 (e6be96084f)

cannot be installed from npm due to an issue in package.json. The fix is
already in place thanks to Julio.

Simon Mac Donald
http://simonmacdonald.com




-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: [DISCUSS] cordova@8 & tools release

[Terence M. Bandoian]

I just tested on Cordova 7.0.0 and was able to successfully add local 
plugins with and without the --no-fetch option.  Seems to have been fixed.


-Terence


On 12/13/2017 11:08 PM, Darryl Pogue wrote:

On Wed, Dec 13, 2017 at 6:15 PM, Terence M. Bandoian <tere...@tmbsw.com> wrote:

Does removing '--no-fetch' apply to adding plugins?  I've recently had to
use that option to get local plugins (file spec) added without hanging.

If there are cases where cordova-fetch is failing to install plugins,
please file bugs so we can know what they are.




-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

[DISCUSS] cordova@8 & tools release

[Terence M. Bandoian]

Does removing '--no-fetch' apply to adding plugins?  I've recently had 
to use that option to get local plugins (file spec) added without hanging.


-Terence Bandoian


On 12/12/2017 12:52 PM, Steven Gill wrote:

Working on getting out a tools release

Doing cordova@8 because we are dropping support for blackberry, webos,
Ubuntu.

Also aiming to remove `--no-fetch` in this release and drop npm dependency
from cordova.

Lastly, `cordova save` command will be dropped in this release too

Any thoughts or feedback?




-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: [Android] Oops...we screwed up in Cordova-Android 5.0.x

[Terence M. Bandoian]

Do it right.  Damn the fallout.

-Terence

On 11/27/2015 4:51 PM, Joe Bowser wrote:

Hey

So, I just came back from Android Dev Summit, and it turns out that we
didn't figure out how to use the
method shouldShowRequestPermissionRationale().  Here's the use case that we
didn't figure out:

If a user refuses a permission twice, they have the option of not showing
the permission prompt ever again.  Basically, this is bad, and the user
should probably use the first callback to explain why this is an issue.
That said, if the user requests the permission a second time, Android Best
Practices state that we should call shouldShowRequestPermissionRationale()
and check to see if it was refused the first time, explain that the
permission requires this permission, and then prompt.

Right now, we can't do that easily without adding an additional API call on
the CordovaInterface.  I think that any changes to CordovaInterface should
automatically prompt a major version update, so I don't want to do this.

So, what should we do with this call? Ignore it? Call it inside the plugin,
and have each plugin handle this independently?  I think that we should
have probably caught this when we were wishing we could explain why we were
requesting certain permissions on our plugins, but hindsight is always
20/20.

So, thoughts on what we should do about this?  Make do without it?

Joe




-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: Adding Telemetry information to Cordova

[Terence M. Bandoian]

Could be useful.  What exactly would be collected?  Would it be 
optional?  Any user identifiable information?


-Terence Bandoian


On 11/3/2015 2:31 AM, julio cesar sanchez wrote:

I think it's a good idea to add it and it will help understand how people
use cordova and find common problems that they might have

2015-11-02 23:13 GMT+01:00 Parashuram N :


Hey folks,

One of the action items from the face to face meeting was about adding the
ability to the Cordova CLI to collect telemetry data. Folks said that they
were not sure if Apache had any policies against it. I checked with
legal-disc...@apache.org (and included
the PMC in the mail) and looks like they don't have any policies for or
against it.
In terms of prior art, Looks like the Apache Flex project is already
collecting limited telemetry, and CloudStack folks are thinking about it.

Now that we know that Apache is not totally against collecting telemetry
data, what do you guys think about it? Are there folks in the community who
are totally against adding any kind of telemetry to Cordova ? If yes, can
we discuss those concerns in this thread ?
Also, are there folks who think this is a good idea ? If yes, please raise
those points too.




-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: Medic Report

[Terence M. Bandoian]

That looks really useful!  Is there any way to change text/background 
colors?


-Terence Bandoian


On 5/2/2015 5:29 PM, Dmitry Blotsky wrote:

Hi list,

Here is this week’s report on test failures:

Android OSX 14
Android Windows 16
iOS 21
Windows 0
WP8 build breaking

Open JIRAs:
https://issues.apache.org/jira/browse/CB-8848 
https://issues.apache.org/jira/browse/CB-8848 | failures iOS  WP8
https://issues.apache.org/jira/browse/CB-8847 
https://issues.apache.org/jira/browse/CB-8847 | failures iOS
https://issues.apache.org/jira/browse/CB-8845 
https://issues.apache.org/jira/browse/CB-8845 | failures Android  iOS
https://issues.apache.org/jira/browse/CB-8844 
https://issues.apache.org/jira/browse/CB-8844 | failures Android
https://issues.apache.org/jira/browse/CB-8843 
https://issues.apache.org/jira/browse/CB-8843 | failures Android
https://issues.apache.org/jira/browse/CB-8842 
https://issues.apache.org/jira/browse/CB-8842 | failures iOS and Android

I have yet to file a JIRA for the WP8 failure.

Medic URI: http://ci.apache.org/waterfall?category=cordova 
http://ci.apache.org/waterfall?category=cordova

Kindly,
Dmitry



-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: Cordova generated .apk file encrypt

[Terence M. Bandoian]

You might also want to consider the Google Closure Compiler.

-Terence


On 2/13/2015 4:39 PM, Carlos Santana wrote:

Danish,
   Like Joe said you can't encrypt your web code (i.e. javascript), at the
end of the day it needs to be parse by the webview in plain text.

Most you can do is obfuscate by using a tools like [1] uglifyjs to remove
comments, and do minification, their are others this is just one.
you can run uglifyjs automatically using a cordova cli hook, you can take a
look here how people are using hooks in their cordova workflow

[1]: https://github.com/mishoo/UglifyJS
[2]:
http://devgirl.org/2013/11/12/three-hooks-your-cordovaphonegap-project-needs/

On Fri, Feb 13, 2015 at 1:54 PM, Joe Bowser bows...@gmail.com wrote:


Why is this a problem?  We currently do not support this use case and do
not have any plans to as far as I'm aware.  Anyone can unzip any APK and
dedex the code to see the Java as well.  This often leads to hilarious
commentary on profanity in what people believed would be private code.

If you have code that you wish to have secret, you really need to make sure
that logic exists entirely on the server side under your control.  Trying
to use cryptography to hide your code on an Android project is probably
just going to end in tears.

On Fri Feb 13 2015 at 10:50:47 AM Danish Khan amdk2...@gmail.com wrote:


HI,

First i would like to thank you for creating cordova. I have made one
application which is based on jquery mobile base in cordova. The only

issue

is i want to encrypt .apk file because any body can change .apk extension
to .zip file  can view all the assest folder html files. i want to

encrypt

that please guide me and help how can i encrypt that files.

Your earlier reply will be highly appreciated

Thanks  Regards,

Danish







-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: Automatically installing missing platforms from cli

[Terence M. Bandoian]

For users, particularly those that don't use Cordova every day, I'd 
prefer a straightforward set of primitives with minimal side effects 
that don't require recollection of much beyond the names of the primitives.


From a development standpoint, my impression is that Cordova is already 
complex enough that it's difficult to move from one release to another 
without breaking something.


Simplicity is good.

-Terence



On 1/12/2015 1:19 PM, Michael Brooks wrote:

By the sounds of it, the Cordova team is not in agreement on whether we
should auto-add platforms with the Cordova CLI.

My two cents is: Fil Maj and I created the Cordova CLI to be an explicit
CLI tool that produced parseable output for programmatic consumption. It's
a tool for distributions to use. The PhoneGap CLI, on the other hand, is a
simple CLI that helps the user and produced human-readable output. It's a
tool for human use. That said, this philosophy has been long lost - the
Cordova CLI is absolutely awful at programmatic usage.

The implementation is trivial but this discussion is important. As a team,
the Cordova contributors need to decide what they want. The worse thing
that can happen is for this feature to be force pushed into `master`
without a positive consensus.


On Mon, Jan 12, 2015 at 9:02 AM, Andrew Grieve agri...@chromium.org wrote:


On Sun, Jan 11, 2015 at 11:40 PM, Terence M. Bandoian tere...@tmbsw.com
wrote:


Creating directories and downloading and installing files is a lot of
magic that may not be desired. Here's another Git example:


Compiling on android downloads  creates a bunch of files, but it  is what
you want it to do. When would this not be desired? It's an easily undo-able
operation.

With git, it's actually really important that you know what each command
does. With cordova, I don't think it's as important that you understand how
it works. You can get by with the fact that it does work.




$ git commit -m commit test.
On branch development
Changes not staged for commit:
 modified:   html/data/topics.json
 modified:   html/topics.html

no changes added to commit

$ git status
On branch development
Changes not staged for commit:
   (use git add file... to update what will be committed)
   (use git checkout -- file... to discard changes in working

directory)

 modified:   html/data/topics.json
 modified:   html/topics.html

no changes added to commit (use git add and/or git commit -a)

On a related note, is there a diagram somewhere of all the cordova-cli
commands and their associated options?

-Terence



On 1/10/2015 7:38 PM, Andrew Grieve wrote:


cordova run already builds before running (unless you add --nobuild).

I

think it'd be pretty annoying if we had run fail with a you need to

build

first kind of message.

In my mind, cordova-cli's purpose is to add magic. Otherwise, you would
just use plugman+platform scripts (and yes, some people do and that is
okay).

I think it would be awesome if you could clone a project, type cordova
run
ios and have it do everything necessary to run the app (install, build,
and deploy).



On Fri, Jan 9, 2015 at 8:13 PM, Jesse purplecabb...@gmail.com wrote:

  what does `cordova run ios` do in windows?

or:
`cordova run wp8` in mac?

Note that recent changes allow you to `platform add ios` in windows,

but

run will always be an error.
Personally, I am with Terrance on this. Magic should be used very
carefully.

--
$ git on up
git: 'on' is not a git command. See 'git --help'.

Did you mean one of these?
  clone
  log
  notes
  svn



@purplecabbage
risingj.com

On Fri, Jan 9, 2015 at 4:53 PM, Terence M. Bandoian tere...@tmbsw.com
wrote:

  Seems to me that:

  cordova run ios

should do just that.  If the platform has not been added, I'd suggest


that


it fail with an informative message that could include the command to
run
to resolve the problem (similar to Git bash).  At this level, deducing


the


user's intentions has the potential to get messy in a hurry both in

the

code and for the user.

-Terence Bandoian



On 1/9/2015 12:47 PM, Michal Mocny wrote:

  I'd like to have cordova-cli automatically install missing platforms
when
it is obvious that the platform is required.  i.e.:

   cordova create Foo  cd Foo


cordova run ios

  ..should just `cordova platform add ios` automatically.

It appears that this was already added to phonegap-cli.  Would Adobe


mind
donating this to cordova-cli, or is it different enough for me to just

start from scratch?  Should be easy, but don't want to duplicate
effort.

Filed: https://issues.apache.org/jira/browse/CB-8283

-Michal




-

To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org




-
To unsubscribe, e-mail: dev-unsubscr

Re: Automatically installing missing platforms from cli

[Terence M. Bandoian]

Creating directories and downloading and installing files is a lot of 
magic that may not be desired. Here's another Git example:


$ git commit -m commit test.
On branch development
Changes not staged for commit:
modified:   html/data/topics.json
modified:   html/topics.html

no changes added to commit

$ git status
On branch development
Changes not staged for commit:
  (use git add file... to update what will be committed)
  (use git checkout -- file... to discard changes in working directory)

modified:   html/data/topics.json
modified:   html/topics.html

no changes added to commit (use git add and/or git commit -a)

On a related note, is there a diagram somewhere of all the cordova-cli 
commands and their associated options?


-Terence


On 1/10/2015 7:38 PM, Andrew Grieve wrote:

cordova run already builds before running (unless you add --nobuild). I
think it'd be pretty annoying if we had run fail with a you need to build
first kind of message.

In my mind, cordova-cli's purpose is to add magic. Otherwise, you would
just use plugman+platform scripts (and yes, some people do and that is
okay).

I think it would be awesome if you could clone a project, type cordova run
ios and have it do everything necessary to run the app (install, build,
and deploy).



On Fri, Jan 9, 2015 at 8:13 PM, Jesse purplecabb...@gmail.com wrote:


what does `cordova run ios` do in windows?
or:
`cordova run wp8` in mac?

Note that recent changes allow you to `platform add ios` in windows, but
run will always be an error.
Personally, I am with Terrance on this. Magic should be used very
carefully.

--
$ git on up
git: 'on' is not a git command. See 'git --help'.

Did you mean one of these?
 clone
 log
 notes
 svn



@purplecabbage
risingj.com

On Fri, Jan 9, 2015 at 4:53 PM, Terence M. Bandoian tere...@tmbsw.com
wrote:


Seems to me that:

 cordova run ios

should do just that.  If the platform has not been added, I'd suggest

that

it fail with an informative message that could include the command to run
to resolve the problem (similar to Git bash).  At this level, deducing

the

user's intentions has the potential to get messy in a hurry both in the
code and for the user.

-Terence Bandoian



On 1/9/2015 12:47 PM, Michal Mocny wrote:


I'd like to have cordova-cli automatically install missing platforms

when

it is obvious that the platform is required.  i.e.:

  cordova create Foo  cd Foo

cordova run ios


..should just `cordova platform add ios` automatically.

It appears that this was already added to phonegap-cli.  Would Adobe

mind

donating this to cordova-cli, or is it different enough for me to just
start from scratch?  Should be easy, but don't want to duplicate effort.

Filed: https://issues.apache.org/jira/browse/CB-8283

-Michal



-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org





-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Automatically installing missing platforms from cli

[Terence M. Bandoian]

Seems to me that:

cordova run ios

should do just that.  If the platform has not been added, I'd suggest 
that it fail with an informative message that could include the command 
to run to resolve the problem (similar to Git bash).  At this level, 
deducing the user's intentions has the potential to get messy in a hurry 
both in the code and for the user.


-Terence Bandoian


On 1/9/2015 12:47 PM, Michal Mocny wrote:

I'd like to have cordova-cli automatically install missing platforms when
it is obvious that the platform is required.  i.e.:


cordova create Foo  cd Foo
cordova run ios

..should just `cordova platform add ios` automatically.

It appears that this was already added to phonegap-cli.  Would Adobe mind
donating this to cordova-cli, or is it different enough for me to just
start from scratch?  Should be easy, but don't want to duplicate effort.

Filed: https://issues.apache.org/jira/browse/CB-8283

-Michal




-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: cordova 64-bit support

[Terence M. Bandoian]

It might make sense to consider dropping support for an iOS version when 
usage, as reported by Apple, drops below a certain level.


-Terence Bandoian


On 11/8/2014 5:13 PM, julio cesar sanchez wrote:

iOS 5 support was removed on cordova 3.5, released on may 2014, I think
it's too soon to remove iOS 6 support with all the devices left behind
(iphone 3gs and ipod touch 4gen), just to add swift plugins.

I'm ok with dropping support to old versions when there are real advantages
or security reasons.

I'm limited on resources too, but I volunteer to test on my ipod touch




-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: Independent platform release summary

[Terence M. Bandoian]

How about 1.0.0 for the CLI version?

-Terence


On 10/9/2014 4:13 PM, Steven Gill wrote:

I think vladimir fixed the bug. We just need to release now.

Only thing holding back the release now is consensus on the version of the
cli. It seemed like most people were leaning toward 10.0.0. Should I move
forward with that? I would just have to branch + pin deps

Leo the documentation version dropdown box would be tied to cli version. It
still makes sense to copy over platform documentation into platform repos
and maybe copy it into docs during generation time.

As for plugin pinning, plugins have more to do with platforms. I wouldn't
say they aren't tied to the cli at all. I understand your point though. So
far, we haven't had any plugins that won't work with previous versions (As
far as I know). We should really fix the engine stuff for plugins so we can
keep track of what platforms they work for. I'd like us to give warnings to
users to update their plugins if newer versions are out. Cordova info
should also dump what versions of plugins you have installed if it doesn't
already. In combination with cordova --save  cordova --restore, we should
be able to recommend a workflow that is easily reproducible on any machine.

On Thu, Oct 9, 2014 at 1:44 PM, Chuck Lantz cla...@microsoft.com wrote:


Okay - so - there's a pretty nasty CLI blocker bug right now.  Plugins
with dependencies don't install (this affects all platforms).  In my
opinion, we need to get a CLI release out really soon.  Are we closed on
this topic, or do we need to look at doing the old process to get this out
the door while we are still talking?

There are also a series of other bugs in the currently tagged 3.6.4
platforms for Android, Windows, and Windows Phone 8.  These can be handled
independently, but the CLI bug can't.

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

-Chuck

-Original Message-
From: Treggiari, Leo [mailto:leo.treggi...@intel.com]
Sent: Thursday, October 9, 2014 12:23 PM
To: Michal Mocny
Cc: Marcel Kinard; dev
Subject: RE: Independent platform release summary

I'll have to admit that this seems a bit weird.  That is, independent
versions of the CLI and platforms, with a Cordova release named
something - e.g. a date?

Imagine a user wants to know whether the new whitelist entry in config.xml
is supported in the versions of CLI and platforms that they have - assuming
they understand the distinction between the CLI and platforms to begin
with.  They use some command to list the versions of the things (CLI and
platforms) they have installed.  They go to the individual documentation of
the things and try to figure it out.

The way the Cordova documentation works today is nice with the combo box
where I can select a Cordova version - 3.6.0, 3.5.0, ...  What would the
combo box contain in the new versioning scheme and how many entries would
there be?  Are the answers dates and lots of dates?  Or would there be
no Cordova version documentation other than an explanation of how to get
the list of things you currently have and where to find the documentation
on them.

To pin or not to pin.

Note that, to me, the pinning choice defines what happens when I use
cordova {plugin | platform} add foo with no specific version specified.

I've understood, so far at least, that plugins are not pinned (an add
always fetches something) and platforms are pinned to a CLI version (an add
tells the CLI that I will be using that platform (already installed) for
this project).  Everything I have read which includes 1 book and the
on-line project documentation, suggest that, even if not stating it
explicitly.  E.g. plugins talk about fetching and platforms don't.  There
is a way to fetch a specific version of platform support.  That's good and
if I do that it is up to me to understand the compatibility of the specific
version I requested.

Is this true?  If so then the npm cordova behavior seems weird.  That is,
if I npm install cordova I get a set of pinned platforms.  If I npm
update cordova, I get a new CLI and nothing else - i.e. not the platforms
that were pinned to that version of the CLI?

Should the plugin and platform 'pin' behavior be the same?

Should both be pinned?  Some may find this alternative blasphemous but
the core plugin versions tested with a version of the CLI could be pinned
to the version of the CLI.

Should both not be pinned?  It would be more consistent and if users are
OK with plugins being unpinned, why not platforms?

But maybe plugins and platforms are different.  Plugins are purely
run-time code.  Platforms are primarily tooling with some run-time code.
Does that difference make the current pinning behavior the best choice.

Maybe, but personally I would prefer both to be pinned - i.e. I install a
version of Cordova, and until I update it, every time I add a platform or
'core' plugin, I get the same thing.

Leo

From: mmo...@google.com [mailto:mmo...@google.com] On Behalf Of Michal
Mocny
Sent: Wednesday, October 

Re: Independent platform release summary

[Terence M. Bandoian]

Oh, well, scratch that idea.  I didn't think about that and wasn't 
trying to be smart.  It's just that you're establishing a new way of 
looking at and doing things and there needs to be a really clear 
distinction between CLI and the platforms.  Seems very significant to 
me.  Huge even.


-Terence


On 10/9/2014 4:32 PM, Steven Gill wrote:

Unfortunately, that would cause more confusion. I am opposed to lowering
the current version. It would cause havoc once the version worked it's way
back up to 3.



On Thursday, October 9, 2014, Terence M. Bandoian tere...@tmbsw.com wrote:


How about 1.0.0 for the CLI version?

-Terence


On 10/9/2014 4:13 PM, Steven Gill wrote:


I think vladimir fixed the bug. We just need to release now.

Only thing holding back the release now is consensus on the version of the
cli. It seemed like most people were leaning toward 10.0.0. Should I move
forward with that? I would just have to branch + pin deps

Leo the documentation version dropdown box would be tied to cli version.
It
still makes sense to copy over platform documentation into platform repos
and maybe copy it into docs during generation time.

As for plugin pinning, plugins have more to do with platforms. I wouldn't
say they aren't tied to the cli at all. I understand your point though. So
far, we haven't had any plugins that won't work with previous versions (As
far as I know). We should really fix the engine stuff for plugins so we
can
keep track of what platforms they work for. I'd like us to give warnings
to
users to update their plugins if newer versions are out. Cordova info
should also dump what versions of plugins you have installed if it doesn't
already. In combination with cordova --save  cordova --restore, we should
be able to recommend a workflow that is easily reproducible on any
machine.

On Thu, Oct 9, 2014 at 1:44 PM, Chuck Lantz cla...@microsoft.com wrote:

  Okay - so - there's a pretty nasty CLI blocker bug right now.  Plugins

with dependencies don't install (this affects all platforms).  In my
opinion, we need to get a CLI release out really soon.  Are we closed on
this topic, or do we need to look at doing the old process to get this
out
the door while we are still talking?

There are also a series of other bugs in the currently tagged 3.6.4
platforms for Android, Windows, and Windows Phone 8.  These can be
handled
independently, but the CLI bug can't.

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

-Chuck

-Original Message-
From: Treggiari, Leo [mailto:leo.treggi...@intel.com]
Sent: Thursday, October 9, 2014 12:23 PM
To: Michal Mocny
Cc: Marcel Kinard; dev
Subject: RE: Independent platform release summary

I'll have to admit that this seems a bit weird.  That is, independent
versions of the CLI and platforms, with a Cordova release named
something - e.g. a date?

Imagine a user wants to know whether the new whitelist entry in
config.xml
is supported in the versions of CLI and platforms that they have -
assuming
they understand the distinction between the CLI and platforms to begin
with.  They use some command to list the versions of the things (CLI
and
platforms) they have installed.  They go to the individual documentation
of
the things and try to figure it out.

The way the Cordova documentation works today is nice with the combo box
where I can select a Cordova version - 3.6.0, 3.5.0, ...  What would the
combo box contain in the new versioning scheme and how many entries would
there be?  Are the answers dates and lots of dates?  Or would there
be
no Cordova version documentation other than an explanation of how to get
the list of things you currently have and where to find the
documentation
on them.

To pin or not to pin.

Note that, to me, the pinning choice defines what happens when I use
cordova {plugin | platform} add foo with no specific version specified.

I've understood, so far at least, that plugins are not pinned (an add
always fetches something) and platforms are pinned to a CLI version (an
add
tells the CLI that I will be using that platform (already installed) for
this project).  Everything I have read which includes 1 book and the
on-line project documentation, suggest that, even if not stating it
explicitly.  E.g. plugins talk about fetching and platforms don't.
There
is a way to fetch a specific version of platform support.  That's good
and
if I do that it is up to me to understand the compatibility of the
specific
version I requested.

Is this true?  If so then the npm cordova behavior seems weird.  That is,
if I npm install cordova I get a set of pinned platforms.  If I npm
update cordova, I get a new CLI and nothing else - i.e. not the
platforms
that were pinned to that version of the CLI?

Should the plugin and platform 'pin' behavior be the same?

Should both be pinned?  Some may find this alternative blasphemous but
the core plugin versions tested with a version of the CLI could be pinned
to the version of the CLI.

Should both not be pinned?  It would

RE: Independent platform release summary

[Terence M. Bandoian]

Getting close.

-Terence


On 10/7/2014 10:15 AM, Treggiari, Leo wrote:

I think (d) is moving in the right direction but would like to put forth some 
additional suggestions.  I do not have the same level of history and experience 
with Cordova (usage and implementation) that many of you do, and so it is 
entirely possible for me to suggest something ridiculous...  ;-)

I think a Cordova release and it's version number, should be reflected in some component version. 
 E.g. when a user talks about Cordova 3.5, it's fairly easy to understand, in general, the 
functionality they have.  The details will depend upon the patch version number.

So, I would tie the Cordova version to the CLI version.  In general, the Cordova  CLI 
version would identify common workflow (CLI) and platform functionality.  Common platform functionality 
is embodied in things like the common entries in config.xml, the default Cordova project (Hello 
Cordova) etc.  This would be what the Cordova version specific documentation would document for the 
.0 patch version (e.g. Cordova version 3.6.0).

Plugin version numbers remain completely independent.  Platform version numbers 
are completely independent as well, but it would be helpful if the platform 
major version number always matched the Cordova major version number.  This 
would mean no incompatible platform functionality changes during the support of 
a major Cordova version.  I don't know if that is realistic.  Maybe changes 
like dropping support for an older platform don't need to require a platform 
major version number change.

The Cordova and CLI major and minor version numbers increment with changes to the workflow 
and common platform functionality - e.g. going from 3.5 - 3.6 added new 
whitelist functionality.  Each Cordova release tests with the latest versions of 
the plugins and latest versions of the platforms.

When a platform releases, regardless of whether it is a major, minor, or patch 
release, the Cordova and CLI version increments the patch version number.  I 
assume that each Cordova release, including patch releases, defines the default 
version of each platform which is used when the user adds a platform without a 
specific version number.

Leo

-Original Message-
From:mmo...@google.com  [mailto:mmo...@google.com] On Behalf Of Michal Mocny
Sent: Monday, October 06, 2014 5:29 PM
To: Smith, Peter
Cc:dev@cordova.apache.org
Subject: Re: Independent platform release summary

Just got through this thread.  Summarizing Proposals:

(a) CLI moves to v10.0.0, and version numbers increment at same rate as
(union of) platforms.
- This has benefits, but is confusing as shit given our current plan.
I'm not sure it needs to be this confusing, but we shouldn't make moves
forward until we think this through some more.
- This kinda conflicts with the whole point of independent releases,
too: a version bump for a platform you don't care about still affects you
(a bit).

(b) CLI version is a sum of all platform versions
- I think this seems an minor management improvement over (a), but falls
apart when you consider what happens when you deprecate a platform in the
future.

(c) We move back to pinning platform versions to CLI version (aka, there
is a single cordova version number shared by everything)
- This conflicts with independant versioning, but maybe not independent
releases (which is what we are really after).
- This implies (I think) releases by date / cadence version, and not
real semver (Or semver but for the union of all platforms and tools, kinda
pointless).
- To do independent platform releases, we should first find a
lightweight way to bump platform versions without a release (i.e.
cordova-ios@3.6.0  - @3.7.0 rename when cordova-android bumps to @3.7.0).
Otherwise, devs will be upgrading platforms for no reason constantly.

(d) CLI versions completely independent of platforms, just like plugins.
- In this case, we need to implement platform-cli version requirements
  (node peerDependancies?)
- Basically means we play down CLI version entirely, users are just
expected to stay up to date with CLI always.  Platform versions are all
that matters.  I don't think this is too different than what we have today.

I personally like (d) most.  Sure, I do like the simplified versioning
story of (c) (basically cad-ver), but I think its less important now that
we are doing platform releases to npm.  I hope we won't rely on users
getting cordova from download links from the website, but rather just npm
upgrade -g.  I think (a) just complicates (d) needlessly without giving
real value to users.

Did I make any mistakes?  Shall we meet to discuss this at PGDay US, or
shall we do a hangout this week if we hope to have something to present to
the audience in time for PGDay US?

-Michal

On Mon, Oct 6, 2014 at 6:37 PM, Smith, Peterpet...@fast.au.fujitsu.com
wrote:


Super version flexibility == Super version confusion.

The Cordova site seems 

Re: OnDeviceReady with unstable behaviour

[Terence M. Bandoian]

From the phonegap 3.5.0 docs:

!DOCTYPE html
html
  head
titleDevice Ready Example/title

script type=text/javascript charset=utf-8 
src=cordova.js/script

script type=text/javascript charset=utf-8

// Wait for device API libraries to load
//
function onLoad() {
document.addEventListener(deviceready, onDeviceReady, false);
}

// device APIs are available
//
function onDeviceReady() {
// Now safe to use device APIs
}

/script
  /head
  body onload=onLoad()
  /body
/html

-Terence


On 8/13/2014 3:52 PM, Carlos Santana wrote:

Like Andrew mentioned too late to add the listener.

Where are you putting your cordova.js? If you are loading it from head
then device ready is firing before you attach.

To be on the super safe side attach the listener  before you load
cordova.js in body, to be on the safe side.



On Wed, Aug 13, 2014 at 2:40 PM, Andrew Grieve agri...@chromium.org wrote:


My guess: Don't wait until onload to register your deviceready listener.


On Wed, Aug 13, 2014 at 1:43 PM, Leonardo Martínez leolib2...@gmail.com
wrote:


Hi,

I am new here and I got into this mailing list because of this strange
behaviour.

The thing is that sometimes the ondeviceready event is not triggerred and
sometimes it is. I could say like the first time the windows is opened
(window.open(...) ) it is not triggered but going back (to another
window) and in again it's triggered.

I have this in the HTML:

body onload=onLoad()
 div id=mainDiv
 div id=deviceready class=blink
 p class=event listeningConnecting to Device/p
 p class=event receivedDevice is Ready/p
 /div


/body

And this function in JS:

function onLoad() {
document.addEventListener(deviceready, onDeviceReady, false);
alert(I was set);
}

function onDeviceReady() {
alert(Hi);
}


I am working with Cordova 3.5.0-0.2.4 and this is happening in iOS. Not

on

Android with the same code.

Hope you can help me. Thanks!

--
Leonardo.

Re: OnDeviceReady with unstable behaviour

[Terence M. Bandoian]

Right. The docs also include the following:

The deviceready event behaves somewhat differently from others. Any 
event handler registered after the deviceready event fires has its 
callback function called immediately.


-Terence


On 8/13/2014 8:29 PM, Joe Bowser wrote:

When subscribing to the events, it should actually run right away if the
event was already fired. This is definitely a regression in cordova.js, or
a design change I didn't catch. Both are possible.
On Aug 13, 2014 5:59 PM, Terence M. Bandoian tere...@tmbsw.com wrote:


Same on http://cordova.apache.org/docs/en/3.5.0/cordova_events_
events.md.html#deviceready.

-Terence


On 8/13/2014 7:51 PM, Terence M. Bandoian wrote:


 From the phonegap 3.5.0 docs:

!DOCTYPE html
html
   head
 titleDevice Ready Example/title

 script type=text/javascript charset=utf-8
src=cordova.js/script
 script type=text/javascript charset=utf-8

 // Wait for device API libraries to load
 //
 function onLoad() {
 document.addEventListener(deviceready, onDeviceReady, false);
 }

 // device APIs are available
 //
 function onDeviceReady() {
 // Now safe to use device APIs
 }

 /script
   /head
   body onload=onLoad()
   /body
/html

-Terence


On 8/13/2014 3:52 PM, Carlos Santana wrote:


Like Andrew mentioned too late to add the listener.

Where are you putting your cordova.js? If you are loading it from head
then device ready is firing before you attach.

To be on the super safe side attach the listener  before you load
cordova.js in body, to be on the safe side.



On Wed, Aug 13, 2014 at 2:40 PM, Andrew Grieve agri...@chromium.org
wrote:

  My guess: Don't wait until onload to register your deviceready listener.


On Wed, Aug 13, 2014 at 1:43 PM, Leonardo Martínez 
leolib2...@gmail.com
wrote:

  Hi,

I am new here and I got into this mailing list because of this strange
behaviour.

The thing is that sometimes the ondeviceready event is not triggerred
and
sometimes it is. I could say like the first time the windows is opened
(window.open(...) ) it is not triggered but going back (to another
window) and in again it's triggered.

I have this in the HTML:

body onload=onLoad()
  div id=mainDiv
  div id=deviceready class=blink
  p class=event listeningConnecting to Device/p
  p class=event receivedDevice is Ready/p
  /div


/body

And this function in JS:

function onLoad() {
document.addEventListener(deviceready, onDeviceReady, false);
alert(I was set);
}

function onDeviceReady() {
alert(Hi);
}


I am working with Cordova 3.5.0-0.2.4 and this is happening in iOS. Not


on


Android with the same code.

Hope you can help me. Thanks!

--
Leonardo.

Re: Experimenting with JSCS + JSHint in cordova-lib

[Terence M. Bandoian]

Nicely done.  Seems reasonable, well-organized and easy to understand.

-Terence Bandoian


On 8/1/2014 3:15 PM, Mark Koudritsky wrote:

With and empty config file JSCS would emit no errors whatsoever. As more
options are added, the more of a style JSCS enforces. Let's try it this
way, I'll split the current config file into 3 sections and people comment
whether they think it should be enforced:

## Part 1, the whitespace basics I've rarely seen disagreement about
Option names are self explanatory.

 disallowMixedSpacesAndTabs: true,
 disallowTrailingWhitespace: true,
 validateLineBreaks: LF,
 validateIndentation: 4,
 requireLineFeedAtFileEnd: true,

## Part 2, not universal but very common conventions.

 disallowSpaceAfterPrefixUnaryOperators: true,
 disallowSpaceBeforePostfixUnaryOperators: true,
 requireSpaceAfterLineComment: true,
 requireCapitalizedConstructors: true,
cordova-lib code currently violates the last one with lower case
constructors for hooker() (but that's being replaces in PR 55
https://github.com/apache/cordova-lib/pull/55) and platfroms[].parser.


## Part 3, somewhat arguable things but mostly adhered to by the existing
cordova-lib code
 // function f(x) is ok but function f (x) is not:
 disallowSpacesInNamedFunctionExpression: {
 beforeOpeningRoundBrace: true
 },
 // if (x0) is ok but if(x0) is not./
 requireSpaceAfterKeywords: [
   if,
   else,
   for,
   while,
   do
 ]

We could potentially add way way more options and create a fully fledged
tight style, but that's definitely not my goal :)



On Fri, Aug 1, 2014 at 2:56 PM, Steven Gill stevengil...@gmail.com wrote:


I personally am a little hesitant to have to follow a certain coding style
+ am worried about outside contributors struggling with it. On the other
hand, it would be nice for code readability to have uniform/consistent
style.

As long as we discuss what styles we want to use beforehand, I am open to
it.


On Thu, Jul 31, 2014 at 7:34 PM, Mark Koudritsky kam...@google.com
wrote:


Just opened a pull request with an experimental JSCS config. Would be

glad

to get some feedback about this. My goal is to eventually run JSCS

together

with JSHint as part of `npm test`. This is a relatively liberal config

that

doesn't generate too many warnings with the existing code.

https://github.com/apache/cordova-lib/pull/69


## Some background

JSHint people want to focus on syntax linting and are dropping style
oriented
options. They recommend using JSCS (in addition to JSHint) for style:
https://github.com/jshint/jshint/issues/1339

Options dropped from JSHint were added to JSCS some time ago:
https://github.com/mdevils/node-jscs/issues/102

I'm using it with SublimeLinter-jscs
https://sublime.wbond.net/packages/SublimeLinter-jscs

Re: Proposal: remove platform versions from platfroms.js

[Terence M. Bandoian]

If I understand the terminology:

- CLI refers to a collection of utilities to download and install 
OS-specific application frameworks and plugins and build applications 
using those frameworks and plugins

- platforms refers to OS-specific software frameworks

If that's true, I would think that a very loose coupling between the two 
would make sense.


Including default versions for platforms and plugins in the CLI seems 
reasonable.  Allowing versions to be specified for platforms and plugins 
in CLI commands seems essential for development flexibility.


-Terence Bandoian


On 7/24/2014 1:17 PM, David Kemp wrote:

It seems to me that:
1) to make our users happy and get them to consider using newer versions,
we need to have the perception of stability. Nice clean, well tested,
co-ordinated releases are a good way to get that. For that reason, I think
a method of providing a 'pinned' release set for the end user is a good way
to deliver that.
2) to make it easy and fast for the various platform contributors to
release new stuff, we need independent platform versioning. That would
allow platforms to move ahead separately - as long as all tooling is
backward compatible.

We should be able to do both.



On Thu, Jul 24, 2014 at 1:38 PM, Brian LeRoux b...@brian.io wrote:


I am against this change. I am in favor of adding platforms via
package.json, however.

We need to version lock our dependencies in the CLI. Testing and bug
resolution will be impossible otherwise. (We did this for that reason.)
However, the Platforms don't need to be synchronized. Platforms can release
as they want and the CLI can pick them up as needs be BUT the versioning of
dependencies needs to be explicit.

The only way 'always grab latest' works is when master is pristine and all
development happens on topic branches only to be merged in when everything
works. That is not a capability we currently have.

This makes it impossible to release new versions of platforms that would
be
usable with the same version of CLI. --- this is a feature, not a bug!
When we want to bump the platforms we *should* have to bump the CLI as it
is a dependency.



On Thu, Jul 24, 2014 at 9:19 AM, Andrew Grieve agri...@chromium.org
wrote:


On Thu, Jul 24, 2014 at 10:40 AM, Chuck Lantz cla...@microsoft.com
wrote:


To me it sounds like we're talking about something bigger than pinning:
What does a Cordova version actually mean?

When new macro-level Cordova features like splash screens and icons
support or perhaps coming up with a way to manage code signing and
packaging without going into native projects are released, we'll need

to

be

able to coordinate a release across a number of different platforms.

  So,

the way I've always thought about this from and end user perspective

is:


Certainly having platforms at different versions will be a change from

what

we've had historically. Still, I think it will be for the better.



-Updating the first digit is done for major Cordova level features that
affect everyone - and force everyone to change


But what if only one platform has a change that requires action? Do we

not

bump the major then?, Or do we bump the major and users of other

platforms

discover it doesn't actually affect them.



-Updating the second digit is about incremental improvements that still
constitute new Cordova level features but may only support certain

platforms

-Updating the last digit ties to bug fixes, perf improvements, and other

things that do not have a direct effect on end users



Two questions:
-How will documentation work if platforms go to versions independent of
one another?  For example, consider this:

 Android goes to Cordova 3.7.0 one week
 iOS goes to Cordova 3.7.0 two weeks later



Does the documentation for the same version update?


I think the easiest way is to just not version the docs. Just have them
always be up-to-date for all released platforms.




-Are we saying that there will never be shared infrastructure across
platforms that the CLI needs?  Otherwise you could get in a situation

where

the CLI revs and only one or two platforms are actually supported.

  Given

Cordova really is about cross-platform/multi-device development, is

that

a

message we want to send to end users?  What about plugins?


The latest version of CLI must always support all plugins (even old

ones),

and all platform versions (even old ones). This (I believe), is already

the

case today, and is not too hard to maintain.




I also think this commits the community to testing the CLI across a

number

of different versions over time. The CLI would need to be validated

across

a number of different major and minor versions which increases the test
burden.


I believe this to already be the case. The current workflow is:

1. Install a platform (say, android 3.2)
2. Update CLI to 3.5.0
3. CLI now expected to work with version of platform you have installed.
4. Decide you want to update your platform 

[GitHub] cordova-docs pull request: CB-3571: update the docs for the splash...

[Terence M. Bandoian]

iOS 6 and iOS 7 have different splash screen sizes.

-Terence


On 7/15/2014 1:08 AM, sgrebnov wrote:

Github user sgrebnov commented on a diff in the pull request:

 https://github.com/apache/cordova-docs/pull/220#discussion_r14918639
   
 --- Diff: docs/en/edge/config_ref/images.md ---

 @@ -135,118 +135,60 @@ Windows8
  
  ## Configuring Splash Screens in the CLI
  
 -Use the Splashscreen API to enable display of an app's introductory

 -splash screen on many platforms.  When working in the CLI, splash
 -screen source files are located within the project's `www/res/screens`
 -subdirectory.
 -
 -Android specifies both portrait- and landscape-oriented splash screen
 -images for low, medium, high, and extra-high resolutions:
 -
 -android/screen-hdpi-landscape.png
 -android/screen-hdpi-portrait.png
 -android/screen-ldpi-landscape.png
 -android/screen-ldpi-portrait.png
 -android/screen-mdpi-landscape.png
 -android/screen-mdpi-portrait.png
 -android/screen-xhdpi-landscape.png
 -android/screen-xhdpi-portrait.png
 -
 -The iOS platform specifies variants for iPhone/iPod and iPad, with
 -variants for retina displays and different orientations. The _568h_
 -file applies to the iPhone 5's taller screen:
 -
 -ios/screen-ipad-landscape-2x.png
 -ios/screen-ipad-landscape.png
 -ios/screen-ipad-portrait-2x.png
 -ios/screen-ipad-portrait.png
 -ios/screen-iphone-landscape-2x.png
 -ios/screen-iphone-landscape.png
 -ios/screen-iphone-portrait-2x.png
 -ios/screen-iphone-portrait.png
 -ios/screen-iphone-portrait-568h-2x.png
 -
 -Windows Phone specifies a single splash screen image:
 -
 -windows-phone/screen-portrait.jpg
 -
 -The following sections detail how to set up splash screens when
 -working with SDKs and related command-line tools described in Platform
 -Guides.
 -
 -Don't forget to install the SplashScreen plugin before trying to use the
 -`navigator.splashscreen.hide()` or `navigator.splashscreen.show()` 
methods.
 -
 -## Splash Screens for the Android Platform
 -
 -Place [9-patch 
image](https://developer.android.com/tools/help/draw9patch.html)
 -files in the Android project's `platforms/android/res/drawable*` 
directories.
 -
 -The size for each should be:
 -
 -- xlarge (xhdpi): at least 960 times; 720
 -- large (hdpi): at least 640 times; 480
 -- medium (mdpi): at least 470 times; 320
 -- small (ldpi): at least 426 times; 320
 -
 -When creating a new Android project, the default splash screen images
 -provided in the Cordova sample app should already be present in the
 -`platforms/android/res/drawable*` directories. Feel free to replace these
 -with your own images.
 -When providing your own splash screen images, you do not need to
 -provide the same permutation of 8 as the Cordova default ones
 -here.  More or less optimization can be used.
 -The `drawable` directory names must follow the Android conventions for
 -supporting
 -[screen 
sizes](http://developer.android.com/guide/practices/screens_support.html) and
 -[alternate 
resources](http://developer.android.com/guide/topics/resources/providing-resources.html#AlternativeResources).
 -
 -In the top-level `config.xml` file (not the one in `platforms`), add the
 -following preferences:
 -
 -preference name=SplashScreen value=screen /
 +In the top-level `config.xml` file (not the one in `platforms`), add 
configuration elements like those specified here.
 +
 +# Example configuration
 +
 +Please notice that the value of the src attribute is relative to the 
project directory and not to the www directory.
 +You can name the source image whatever you like. The internal name in the 
app are determined by Cordova.
 +
 +platform name=android
 +!-- you can use any density that exists in the Android project 
--
 +splash src=res/screen/android/splash-land-hdpi.png 
density=land-hdpi/
 +splash src=res/screen/android/splash-land-ldpi.png 
density=land-ldpi/
 +splash src=res/screen/android/splash-land-mdpi.png 
density=land-mdpi/
 +splash src=res/screen/android/splash-land-xhdpi.png 
density=land-xhdpi/
 +
 +splash src=res/screen/android/splash-port-hdpi.png 
density=port-hdpi/
 +splash src=res/screen/android/splash-port-ldpi.png 
density=port-ldpi/
 +splash src=res/screen/android/splash-port-mdpi.png 
density=port-mdpi/
 +splash src=res/screen/android/splash-port-xhdpi.png 
density=port-xhdpi/
 +/platform
 +
 +platform name=ios
 +!-- images are 

Re: adding platforms to npm for dependency sanity

[Terence M. Bandoian]

This is helpful.  Thank you for posting this, Carlos.  I have a couple 
of related questions.


The config files I've used iOS and Android are significantly different 
for the same project.  Is combining everything for all platforms into 
one config.xml recommended?


What cordova commands cause the www folder to be copied to a platforms 
directory?  My workflow for iOS/Xcode is typically (similar for 
Android/Eclipse):


- add/build iOS platform using cordova
- edit, build, test iteratively in Xcode using platforms/ios directory

Xcode doesn't copy from the outer www directory when it builds. Should 
it?  All of the files added to the Xcode project are in the 
platforms/ios directory.


-Terence


On 6/4/2014 10:10 AM, Carlos Santana wrote:

I think regardless how much sugar we use to make it easy, I think the under
the hood foundation/architecture should be something like:

LocalProject/www/
LocalProject/config.xml
LocalProject/package.json
LocalProject/node_module/.bin/cordova

config.xml (manages the cordova app)
package.json (manages the cordova project)

pacakge.json (will specify all dependencies and npm will take care of
fulfill them)
{
cordova: 3.6,
cordova-ios: 3.6.1,
cordova-android: 3.6.2,
cordova-plugin-device: *,
cordova-plugin-file: ^0.2.4
}
npm install will take care of making everything available locally.

I know that we don't have plugins in npm, but something to think about, in
terms of just a secondary repository to download the files and caching.

a global @cordova-cli, can be available like grunt-cli, to look first in
local directory (i.e. findup)

like someone mentioned npm installs hooks can run the cordova platform add

this way minimal set of files can be put a dev repo, and reproduce by
another developer very easy both getting same resulting project.

git clone https://github.com/myuser/cordovapp  cd cordovapp  npm
install  cordova run android



On Tue, Jun 3, 2014 at 6:35 PM, Terence M. Bandoian tere...@tmbsw.com
wrote:


I still consider myself a relative newcomer to Cordova but, from a
development standpoint, it would be easiest for me if I could manage each
platform of a project independently - including plugins.  Creating a
parallel project to make sure that the plugins and Cordova base don't
change for one platform while I work on another isn't ideal but it isn't
completely unmanageable either.  It just makes the workflow a little more
complex.

-Terence



On 6/3/2014 7:12 PM, Michal Mocny wrote:


We don't do platform-plugin version matching *at all* today.  Everyone
uses
the latest plugins and any platform version they want, and its been
fine.
   So using different platform versions isn't as hard as you guys are
making
it out to be.

Still, I've already said its not necessarily a complexity that needs to be
addressed in a world where you can create multiple projects and use
--link-to or whatever, so long as your platforms aren't installed
globally.


Anyway, thanks for posting your instructions Brian/Tommy.  As I mentioned
it would be, thats a different workflow than we have now.  I'm going to
sleep on it before I comment, but it certainly isn't just like You know
how we do it today.

-Michal


On Tue, Jun 3, 2014 at 7:59 PM, tommy-carlos williams to...@devgeeks.org
wrote:

  I don’t think you really can forget about plugins for a second.

In my personal opinion, the entire ./platforms folder should be a build
artefact. If you want to freeze iOS, then use a branch or a new clone of
the project.

It’s not that I can think of no scenarios where supporting multiple
platform versions would be needed, it’s just that I think it’s needlessly
complex vs using a dev workflow to solve those problems.

I already version cordova within a project… I have a local version of
cordova installed into ./node_modules for each project and use Grunt to
call ./node_modules/.bin/cordova rather than the global cordova cli.

On 4 June 2014 at 9:46:29, Terence M. Bandoian (tere...@tmbsw.com)
wrote:

Forgetting about plugins for a second, what if:

- I complete a project for iOS
- six months later the client decides to port to Android and:
- I want the latest fixes for Android
- I want to keep the iOS version frozen for the time being

I would expect releases for each platform to be on different schedules.

-Terence


On 6/3/2014 6:17 PM, Michal Mocny wrote:


Most plugins will work across a wide range of platform versions, so
often
it would work to have disparate platform versions even with plugins.
However, I do concede that in general this isn't a complexity we focus


on.


Interested in your thoughts about the other points.

-Michal


On Tue, Jun 3, 2014 at 7:07 PM, tommy-carlos williams 


to...@devgeeks.org


wrote:

  You can’t have version x of a plugin for iOS and version y of that same

plugin for Android, so multiple platform versions seems like a


complexity
for complexity’s sake.

It’s true that different apps need to support different platform


versions,
but I would suspect

Re: adding platforms to npm for dependency sanity

[Terence M. Bandoian]

Why is having different versions of platforms a recipe for disaster?

-Terence


On 6/4/2014 4:29 PM, Brian LeRoux wrote:

As discussed: having different versions of platforms and plugins is a
recipe for disaster. The design choice of version locking is deliberate to
avoid that. I'm going to ignore the ramble about grunt, etc. I'm not
advocating for that nor am I interested in javascript build library
fashion. Those things are not problems we seek to solve here.

Also: this is not talk. Its building consensus to *continue* the work being
done into a direction that everyone feels good about. The alternative is
patchbombing and a massive delete of google employee commits which is
probably not productive.



On Wed, Jun 4, 2014 at 2:16 PM, Andrew Grieve agri...@chromium.org wrote:


Brian's and Carlos' examples have a very important difference:

Brian's: platforms are dependencies of CLI
Carlos': platforms are siblings of CLI in top-level package.json

With Carlos', the user can easily control versions of the platforms, which
is great. You could just as easily put plugins in there now that npm
supports multiple registries as well.

I don't think you'd need CLI at all with this setup. Just use plugman 
grunt  recreate your project on every build. I think it's a nice workflow,
but I'm afraid that dramatically changing out documented workflow again so
soon would be an unwelcome change. I also think it'd be a good amount of
work to make our tools smart enough to work alongside npm in a way that
isn't confusing (e.g. if we're recreating every time, we'll need to speed
it up a lot. If not, then you need to tell it when dependencies change).

My main goal for now is to get to where we can release platforms
independently, but I'm curious if this is all talk or is anyone intending
to do some real exploration in this area?







On Wed, Jun 4, 2014 at 4:55 PM, Brian LeRoux b...@brian.io wrote:


Here is an example using our current situation. Cordova is versioned [1]
and the CLI calls are abstracted as npm scripts [2]. If we change to the
proposed 'versioning platforms using npm' we don't have to download
platforms, cache them or perform any custom dependency logic.

We will then be well on the path to making the CLI *really* dumb and it
will only pass calls down to the lib installed in node_modules.

HTH

[1]



https://github.com/brianleroux/cordova-example-using-npm/blob/master/package.json#L13

[2]



https://github.com/brianleroux/cordova-example-using-npm/blob/master/package.json#L8


On Wed, Jun 4, 2014 at 1:38 PM, Carlos Santana csantan...@gmail.com
wrote:


Michal
   The grunt plugin and yeoman generator I implemented a long ago. So

it's

implemented on top of what cordova provides.

I'm confuse, this is the point I was trying to get that there is user
space and cordova platform space, Doing a plugin for yeoman, gulp ,
grunt, or the next thing is user space.

cordova as a platform should be using flexbile and clear on what is

doing,

so user space can customize on top of it.


On Wed, Jun 4, 2014 at 12:44 PM, Terence M. Bandoian 

tere...@tmbsw.com

wrote:


This is helpful.  Thank you for posting this, Carlos.  I have a

couple

of

related questions.

The config files I've used iOS and Android are significantly

different

for

the same project.  Is combining everything for all platforms into one
config.xml recommended?

What cordova commands cause the www folder to be copied to a

platforms

directory?  My workflow for iOS/Xcode is typically (similar for
Android/Eclipse):

- add/build iOS platform using cordova
- edit, build, test iteratively in Xcode using platforms/ios

directory

Xcode doesn't copy from the outer www directory when it builds.

Should

it?

  All of the files added to the Xcode project are in the platforms/ios
directory.

-Terence



On 6/4/2014 10:10 AM, Carlos Santana wrote:


I think regardless how much sugar we use to make it easy, I think

the

under
the hood foundation/architecture should be something like:

LocalProject/www/
LocalProject/config.xml
LocalProject/package.json
LocalProject/node_module/.bin/cordova

config.xml (manages the cordova app)
package.json (manages the cordova project)

pacakge.json (will specify all dependencies and npm will take care

of

fulfill them)
{
cordova: 3.6,
cordova-ios: 3.6.1,
cordova-android: 3.6.2,
cordova-plugin-device: *,
cordova-plugin-file: ^0.2.4
}
npm install will take care of making everything available locally.

I know that we don't have plugins in npm, but something to think

about,

in

terms of just a secondary repository to download the files and

caching.

a global @cordova-cli, can be available like grunt-cli, to look

first

in

local directory (i.e. findup)

like someone mentioned npm installs hooks can run the cordova

platform

add

this way minimal set of files can be put a dev repo, and reproduce

by

another developer very easy both getting same resulting project.

git clone https://github.com/myuser/cordovapp  cd

Re: adding platforms to npm for dependency sanity

[Terence M. Bandoian]

First, thanks to everyone on the list for being so patient and answering 
my questions.  It is much appreciated.


What I understand so far is that the plugin code for a given platform 
must be in sync with that platform.  Makes perfect sense.  I've also 
seen that the core plugin APIs are consistent across platforms.  Really 
good.  Given that, my next question would have to be is backwards 
compatibility maintained for the plugin APIs from one release to the 
next?  If it is, shouldn't my application code for a plugin on a given 
version of one platform run unchanged on a (somewhat) newer version of a 
different platform?


-Terence


On 6/4/2014 6:07 PM, tommy-carlos williams wrote:

WRT plugins not being tied to a version of the platforms… We at SpiderOak have 
a project that is still stuck at 3.0.0 for precisely that reason.

As for the CLI not being tied to a platform version, that’s also not true. 
Don’t know if you have tried it, but using a current version of the CLI with a 
project created and “platformed” with a previous version is also a recipe for 
disaster.



On 5 June 2014 at 8:48:48, Brian LeRoux (b...@brian.io) wrote:

Plugins have to target specific versions. [1] Core plugins, our org.apache
plugins, are cross platform. [2]

This is not conceptual but the current reality and a correct software
practice.

[1]
https://github.com/apache/cordova-plugin-inappbrowser/blob/master/plugin.xml#L33
[2] https://github.com/apache/cordova-plugin-inappbrowser/tree/master/src


On Wed, Jun 4, 2014 at 5:32 PM, Terence M. Bandoian tere...@tmbsw.com
wrote:


Why is having different versions of platforms a recipe for disaster?
  
-Terence
  
  
On 6/4/2014 4:29 PM, Brian LeRoux wrote:
  

As discussed: having different versions of platforms and plugins is a
recipe for disaster. The design choice of version locking is deliberate to
avoid that. I'm going to ignore the ramble about grunt, etc. I'm not
advocating for that nor am I interested in javascript build library
fashion. Those things are not problems we seek to solve here.
  
Also: this is not talk. Its building consensus to *continue* the work

being
done into a direction that everyone feels good about. The alternative is
patchbombing and a massive delete of google employee commits which is
probably not productive.
  
  
  
On Wed, Jun 4, 2014 at 2:16 PM, Andrew Grieve agri...@chromium.org

wrote:
  
Brian's and Carlos' examples have a very important difference:
  
Brian's: platforms are dependencies of CLI

Carlos': platforms are siblings of CLI in top-level package.json
  
With Carlos', the user can easily control versions of the platforms,

which
is great. You could just as easily put plugins in there now that npm
supports multiple registries as well.
  
I don't think you'd need CLI at all with this setup. Just use plugman 

grunt  recreate your project on every build. I think it's a nice
workflow,
but I'm afraid that dramatically changing out documented workflow again
so
soon would be an unwelcome change. I also think it'd be a good amount of
work to make our tools smart enough to work alongside npm in a way that
isn't confusing (e.g. if we're recreating every time, we'll need to speed
it up a lot. If not, then you need to tell it when dependencies change).
  
My main goal for now is to get to where we can release platforms

independently, but I'm curious if this is all talk or is anyone intending
to do some real exploration in this area?
  
  
  
  
  
  
  
On Wed, Jun 4, 2014 at 4:55 PM, Brian LeRoux b...@brian.io wrote:
  
Here is an example using our current situation. Cordova is versioned [1]

and the CLI calls are abstracted as npm scripts [2]. If we change to the
proposed 'versioning platforms using npm' we don't have to download
platforms, cache them or perform any custom dependency logic.
  
We will then be well on the path to making the CLI *really* dumb and it

will only pass calls down to the lib installed in node_modules.
  
HTH
  
[1]
  
  
https://github.com/brianleroux/cordova-example-

using-npm/blob/master/package.json#L13
  

[2]
  
  
https://github.com/brianleroux/cordova-example-

using-npm/blob/master/package.json#L8
  
  
On Wed, Jun 4, 2014 at 1:38 PM, Carlos Santana csantan...@gmail.com

wrote:
  
Michal

The grunt plugin and yeoman generator I implemented a long ago. So
  

it's
  

implemented on top of what cordova provides.
  
I'm confuse, this is the point I was trying to get that there is user

space and cordova platform space, Doing a plugin for yeoman, gulp ,
grunt, or the next thing is user space.
  
cordova as a platform should be using flexbile and clear on what is
  

doing,
  

so user space can customize on top of it.
  
  
On Wed, Jun 4, 2014 at 12:44 PM, Terence M. Bandoian 
  

tere...@tmbsw.com
  

wrote:
  
This is helpful. Thank you for posting this, Carlos. I have a
  

couple
  

of
  

related questions.
  
The config files I've used iOS and Android are significantly
  

different

Re: adding platforms to npm for dependency sanity

[Terence M. Bandoian]

.'));
 }
 var pkg = 'cordova-' + platform + '@' +
platforms[platform].version;
 return Q.nfcall( npm.load, {cache:

path.join(util.libDirectory,

'npm_cache') })
 .then(function() {
 return Q.ninvoke(npm.commands, 'cache', ['add',

pkg]);

 }).then(function(info) {
 var pkgDir = path.resolve(npm.cache, info.name,

info.version,

'package');
 return pkgDir;
 });
 },

There's really no amount of code argument here.




Adding platforms at a specific version would mean having a

specific

version

of the CLI. Yes: this is way better! Explicit dependencies is

the

best

way

to work w/ the small modules thing.


Bundling platforms with CLI would be like bundling all of the

plugins

with

CLI, or like bundling every npm module with npm.

Devs need to be able to try out platforms at different versions.

We

should

not do anything that keeps users clinging to old versions of CLI

(e.g.

they

do this now because they don't want to update to new platforms)







On Mon, Jun 2, 2014 at 7:34 PM, Michal Mocny 

mmo...@chromium.org

wrote:

On Mon, Jun 2, 2014 at 10:14 PM, Andrew Grieve 

agri...@chromium.org

wrote:


Here's both flows as I understand them:

Direct NPM flow:
# Downloads platform source into node_modules
npm install cordova-ios@3.4.0 --save
# Runs the create script and installs plugins to create

platforms/ios

cordova platform add ios --path=node_modules/cordova-ios


To be fair, I think with Brian's suggestion, platform add FOO

would

by

default look in node_modules so you wouldn't be explicit

about

it,

and

also

the default cordova project package.json would depend on all

the

latest

versions of each platform, so the flows would actually be:

cordova create Foo  cd Foo
npm install
npm install cordova-ios@3.4 --save
cordova platform add android
cordova platform add ios
# crazy idea? use npm post-install hooks to auto-run

create/upgrade

so

you usually don't need above two lines?

Compared to:

cordova create Foo  cd Foo
cordova platform add android
cordova platform add ios@3.4

I think #2 is enough better that its not worth changing.



Cordova-to-npm flow (as Mark's implemented):
# Runs npm cache add cordova-ios, then runs create script

from

~/cache/cordova-ios/bin/create
cordova platform add ios@3.4.0

- In both flows: we use npm to do all of the heavy lifting
- In both flows: the npm module is cached in your home

directory

- In both flows?: we store the plugins  platforms

explicitly

within

config.xml (Gorkem's added this)
- In flow #1, we have a package.json  a node_modules, in

#2

we

don't.

Why put the onus on the user to fetch the platform source

when

it's

as

easy

as running npm cache add under-the-hood?


In regards to the idea of using require() on platform

scripts

instead

of

subshelling: I think this is tangental to the debate of how

to

fetch

the

platform.
In regards to using npm install directly when using the

plugman

workflow:

Sounds good to me.




On Mon, Jun 2, 2014 at 6:05 PM, Brian LeRoux b...@brian.io

wrote:

Eventually, yes. (Sort of how Grunt works now.)


On Mon, Jun 2, 2014 at 5:52 PM, Terence M. Bandoian 

tere...@tmbsw.com

wrote:


Can multiple versions of a platform be installed

side-by-side?

-Terence



On 6/2/2014 3:04 PM, Michal Mocny wrote:


From original email: Ideal future CLI uses platforms

just

like

other

deps.
We lose lazy loading but network and disk is cheap so

it

wasn't

really

important anyhow.
Made me think Brian is proposing adding platforms to

cli

package.json

dependencies, and you would have a single global

install

cordova-platforms.
   Then you can override the version with an explicit

install

as

he

mentions
npm i cordova-ios@3.5.0.

Personally, I think that workflow could work, and has

a

few

benefits,

but

I'm not sure that option compares well to the

alternative

of

just

lazy

loading using npm cache add as Mark has already

implemented

an

experiment

(anyone interested in this topic should take a look at

that

patch).

The steps Brian  Ian outline about how to package

platforms

for

release

to
npm are possibly an improvement over the old-style

platform-centric

workflow.  Instead of downloading a tarball and

running

a

create

script,

you npm install and run a create() function, and that

can

more

easily

be

bundled into other build scripts/boilerplate.  For CLI

workflow,

not

sure

that there is any real difference (as Jesse says).

  One

note,

though:

   cordova-* platforms are templates for projects, so

the

package.json

of

the
npm package itself shouldn't end up inside projects

that

are

created

with

it. I think.

-Michal


On Mon, Jun 2, 2014 at 3:42 PM, Ian Clelland 

iclell...@chromium.org

wrote:

  There seems to be some confusion -- I think people

are

talking

about

different things here, but perhaps it's just me ;)

I thought that Brian's original suggestion was about

being

able

Re: adding platforms to npm for dependency sanity

[Terence M. Bandoian]

Forgetting about plugins for a second, what if:

- I complete a project for iOS
- six months later the client decides to port to Android and:
- I want the latest fixes for Android
- I want to keep the iOS version frozen for the time being

I would expect releases for each platform to be on different schedules.

-Terence


On 6/3/2014 6:17 PM, Michal Mocny wrote:

Most plugins will work across a wide range of platform versions, so often
it would work to have disparate platform versions even with plugins.
  However, I do concede that in general this isn't a complexity we focus on.

Interested in your thoughts about the other points.

-Michal


On Tue, Jun 3, 2014 at 7:07 PM, tommy-carlos williams to...@devgeeks.org
wrote:


You can’t have version x of a plugin for iOS and version y of that same
plugin for Android, so multiple platform versions seems like a complexity
for complexity’s sake.

It’s true that different apps need to support different platform versions,
but I would suspect that the greatest majority of those would want the same
version of iOS and Android in app x.



On 4 June 2014 at 9:04:42, Brian LeRoux (b...@brian.io) wrote:

That is the thing: you do not EVER want to have disparate versions of
platforms. Plugins negate this potential fantasy.

You want version locked deps. You want to use package.json to do that b/c
that is what the runtime we use has standardized itself on.


On Tue, Jun 3, 2014 at 1:12 PM, Terence M. Bandoian tere...@tmbsw.com
wrote:


A typical use case might be:

-project1
-project1-ios
-project1-android
-project1-windows
...
-projectN
-projectN-ios
-projectN-android
-projectN-windows

with a different platform version for each sub-project.

Would CLI be installed globally? Locally for each sub-project? Would a
project-platform have to be re-built if a plugin were added?

-Terence


On 6/3/2014 1:47 PM, Michal Mocny wrote:


Okay, so I think that implies:

(a) CLI versions tied to very specific platform versions == to switch
platform versions you must switching CLI versions == switching one
platform version switches all platform versions.
- Andrew pointed out this is currently the case, and is a problem that
leads to users not updating CLI as often as they otherwise would
- I think this basically implies platforms cannot be independently
versioned (sure the semver numbers may differ, but for all practical
purposes, you would use platforms from the same release date, based on

CLI

version).

(b) Require apps to depend on specific CLI version, assuming you mean

with

a local package.json:
- Now all cordova projects must be node projects, which they currently

are

not.
- Currently the cordova-cli creates apps, so we have a globally

installed

bootstrapping cordova-cli, and a locally installed specific version
cordova-cli, a-la grunt/gulp. (this idea was thrown around before).
- Quite a dramatic change for cordova workflow, surely larger than the
current proposal.
- Or we drop cordova-cli entirely and just publish grunt/gulp plugins to
add cordova to your existing web app. Thats an even more radical
departure and significant work.

-Michal


On Tue, Jun 3, 2014 at 1:58 PM, Brian LeRoux b...@brian.io wrote:

No, at least not how I'd see it done.

1.) Updating is important. Staying current: encouraged.
2.) I'd make my App depend on a specific CLI version. I'd call into

that

using npm scripts.




On Tue, Jun 3, 2014 at 10:48 AM, Michal Mocny mmo...@chromium.org
wrote:

Thinking it through, if cordova platforms are deps of the CLI, to
install a


specific version you wouldn't just do:


npm install -g cordova-ios@3.4.1


you would actually need to:


cd $(npm config get prefix)/lib/node_modules/cordova
npm install --save cordova-ios@3.4.1


..and then remember to do that again whenever you `npm update -g`
..and its harder to have multiple platform versions for different


projects


(questionable if this is useful for devs outside of cordova
contributors,
but may be useful at last test upgrades when we ship new platform
versions).

-Michal


On Tue, Jun 3, 2014 at 1:28 PM, Brian LeRoux b...@brian.io wrote:

NIH: not invented here



On Tue, Jun 3, 2014 at 10:17 AM, Andrew Grieve agri...@chromium.org
wrote:

On Tue, Jun 3, 2014 at 12:19 PM, Brian LeRoux b...@brian.io wrote:

Actually that was 0 LOC which is a fine argument if you ask me.
And

we


both know there is much more to it than just that. lazy_load…for

example.
If you're concerned about code, there is a tonne of much


lower-hanging

fruit.


Bundling platforms is bundling a dep that we require to operate. We
do

not

require plugins to operate. You cannot build a project without


having a

platform and, indeed, you probably want more than one.

I don't require blackberry to create an iOS project. But I do

require


some


plugins. We use npm cache add to download plugins, I don't see how
platforms would not work just as easily.


Agree that we need discreet versioning: hence why I'm advocating we
use

Re: adding platforms to npm for dependency sanity

[Terence M. Bandoian]

I still consider myself a relative newcomer to Cordova but, from a 
development standpoint, it would be easiest for me if I could manage 
each platform of a project independently - including plugins.  Creating 
a parallel project to make sure that the plugins and Cordova base don't 
change for one platform while I work on another isn't ideal but it isn't 
completely unmanageable either.  It just makes the workflow a little 
more complex.


-Terence


On 6/3/2014 7:12 PM, Michal Mocny wrote:

We don't do platform-plugin version matching *at all* today.  Everyone uses
the latest plugins and any platform version they want, and its been fine.
  So using different platform versions isn't as hard as you guys are making
it out to be.

Still, I've already said its not necessarily a complexity that needs to be
addressed in a world where you can create multiple projects and use
--link-to or whatever, so long as your platforms aren't installed globally.


Anyway, thanks for posting your instructions Brian/Tommy.  As I mentioned
it would be, thats a different workflow than we have now.  I'm going to
sleep on it before I comment, but it certainly isn't just like You know
how we do it today.

-Michal


On Tue, Jun 3, 2014 at 7:59 PM, tommy-carlos williams to...@devgeeks.org
wrote:


I don’t think you really can forget about plugins for a second.

In my personal opinion, the entire ./platforms folder should be a build
artefact. If you want to freeze iOS, then use a branch or a new clone of
the project.

It’s not that I can think of no scenarios where supporting multiple
platform versions would be needed, it’s just that I think it’s needlessly
complex vs using a dev workflow to solve those problems.

I already version cordova within a project… I have a local version of
cordova installed into ./node_modules for each project and use Grunt to
call ./node_modules/.bin/cordova rather than the global cordova cli.

On 4 June 2014 at 9:46:29, Terence M. Bandoian (tere...@tmbsw.com) wrote:

Forgetting about plugins for a second, what if:

- I complete a project for iOS
- six months later the client decides to port to Android and:
- I want the latest fixes for Android
- I want to keep the iOS version frozen for the time being

I would expect releases for each platform to be on different schedules.

-Terence


On 6/3/2014 6:17 PM, Michal Mocny wrote:

Most plugins will work across a wide range of platform versions, so often
it would work to have disparate platform versions even with plugins.
However, I do concede that in general this isn't a complexity we focus

on.

Interested in your thoughts about the other points.

-Michal


On Tue, Jun 3, 2014 at 7:07 PM, tommy-carlos williams 

to...@devgeeks.org

wrote:


You can’t have version x of a plugin for iOS and version y of that same
plugin for Android, so multiple platform versions seems like a

complexity

for complexity’s sake.

It’s true that different apps need to support different platform

versions,

but I would suspect that the greatest majority of those would want the

same

version of iOS and Android in app x.



On 4 June 2014 at 9:04:42, Brian LeRoux (b...@brian.io) wrote:

That is the thing: you do not EVER want to have disparate versions of
platforms. Plugins negate this potential fantasy.

You want version locked deps. You want to use package.json to do that

b/c

that is what the runtime we use has standardized itself on.


On Tue, Jun 3, 2014 at 1:12 PM, Terence M. Bandoian tere...@tmbsw.com
wrote:


A typical use case might be:

-project1
-project1-ios
-project1-android
-project1-windows
...
-projectN
-projectN-ios
-projectN-android
-projectN-windows

with a different platform version for each sub-project.

Would CLI be installed globally? Locally for each sub-project? Would a
project-platform have to be re-built if a plugin were added?

-Terence


On 6/3/2014 1:47 PM, Michal Mocny wrote:


Okay, so I think that implies:

(a) CLI versions tied to very specific platform versions == to switch
platform versions you must switching CLI versions == switching one
platform version switches all platform versions.
- Andrew pointed out this is currently the case, and is a problem that
leads to users not updating CLI as often as they otherwise would
- I think this basically implies platforms cannot be independently
versioned (sure the semver numbers may differ, but for all practical
purposes, you would use platforms from the same release date, based on

CLI

version).

(b) Require apps to depend on specific CLI version, assuming you mean

with

a local package.json:
- Now all cordova projects must be node projects, which they currently

are

not.
- Currently the cordova-cli creates apps, so we have a globally

installed

bootstrapping cordova-cli, and a locally installed specific version
cordova-cli, a-la grunt/gulp. (this idea was thrown around before).
- Quite a dramatic change for cordova workflow, surely larger than the
current proposal.
- Or we drop cordova-cli entirely

Re: Android Plugin API

[Terence M. Bandoian]

It does get complicated in a hurry. Using the technique in the Google 
Maps plugin:


- getDeclaredMethod is documented to NOT return inherited methods which 
limits exposure

- the signature passed to getDeclaredMethod also limits exposure
- annotations, as Andrew suggested, could further limit exposure

- getDeclaredMethod is documented to return private methods which for me 
raises questions
- setAccessible(true) suppresses normal access checking which also 
raises questions


- invoke throws InvocationTargetException so exceptions thrown by the 
invoked method could be publicized

- invoke applies overriding which is probably a wash
- invoke returns an object which would have to be handled correctly

Quite a bit to consider.

-Terence Bandoian


On 5/29/2014 11:44 PM, Joe Bowser wrote:

On Thu, May 29, 2014 at 9:26 PM, Terence M. Bandoian tere...@tmbsw.com wrote:

Please correct me if I'm wrong but, as I understand it, the vulnerability
stems from injecting a Java object into the WebView which, in API levels 16
and below, exposed all of the public methods of the object (small 'o')
including the methods inherited from the Object class.


Yes, you are correct in this case.  You can basically use the object
methods to reflect into whatever you want.  Once you have a single
class exposed in this manner, you can then reflect into it, and
basically you're done.  The reason we don't use reflection is that
it's very easy to reflect into things you're not supposed to be in.
IMO, It wouldn't be hard to do this if we exposed plugins in the same
way.  Right now this is an Android Vulnerability, but if we start
using reflection for plugins, we could very quickly end up making a
similar Cordova exploit if we're not careful.

This is also why we use the prompt bridge on API levels below 17.




On 5/28/2014 9:54 AM, Joe Bowser wrote:

In case anyone is curious, here's why we minimize reflection:


https://labs.mwrinfosecurity.com/blog/2013/09/24/webview-addjavascriptinterface-remote-code-execution/

On Wed, May 28, 2014 at 7:33 AM, Andrew Grieve agri...@chromium.org
wrote:

Another reasonable approach would be to use a MapString, Runnable, but
that can be implemented on top of what is currently exposed. I'm quite
wary
of Reflection as well.


On Wed, May 28, 2014 at 10:06 AM, Joe Bowser bows...@gmail.com wrote:


The execute command exists for security reasons.  We don't want any
methods other than execute exposed to Javascript.  I also prefer this
approach because it is less prone to less catastrophic bugs than using
Java reflection.  We try and only use reflection when we have to.

On Wed, May 28, 2014 at 5:50 AM, Erik Jan de Wit ede...@redhat.com
wrote:

Hi,

When one is writing a plugin for android ATM the api that you have to

implement has a execute method that has the action as a string:

@Override
  public boolean execute(String action, JSONArray args,

CallbackContext callbackContext) throws JSONException {

  if (beep.equals(action)) {
  this.beep(args.getLong(0));
  callbackContext.success();
  return true;
  }
  return false;  // Returning false results in a
MethodNotFound

error.

  }
When you have multiple actions this method gets very long, if you

compare this with iOS here you don’t need a method like this you could
‘just’ implement the method directly:

- (void)beep:(CDVInvokedUrlCommand*)command
  {
  CDVPluginResult* pluginResult =;
  NSString* myarg =mmand.arguments objectAtIndex:0];

  if (myarg !=) {
  pluginResult �VPluginResult

resultWithStatus:CDVCommandStatus_OK];

  } else {
  pluginResult �VPluginResult

resultWithStatus:CDVCommandStatus_ERROR messageAsString:@Arg was
null];

  }
  [self.commandDelegate sendPluginResult:pluginResult

callbackId:command.callbackId];

  }
We could do the same thing for android if we use reflection, making the

API more similar and removing all the string test by the user. What do
you
think?

Cheers,
  Erik Jan

Re: Android Plugin API

[Terence M. Bandoian]

Please correct me if I'm wrong but, as I understand it, the 
vulnerability stems from injecting a Java object into the WebView which, 
in API levels 16 and below, exposed all of the public methods of the 
object (small 'o') including the methods inherited from the Object class.


-Terence Bandoian


On 5/28/2014 9:54 AM, Joe Bowser wrote:

In case anyone is curious, here's why we minimize reflection:

https://labs.mwrinfosecurity.com/blog/2013/09/24/webview-addjavascriptinterface-remote-code-execution/

On Wed, May 28, 2014 at 7:33 AM, Andrew Grieve agri...@chromium.org wrote:

Another reasonable approach would be to use a MapString, Runnable, but
that can be implemented on top of what is currently exposed. I'm quite wary
of Reflection as well.


On Wed, May 28, 2014 at 10:06 AM, Joe Bowser bows...@gmail.com wrote:


The execute command exists for security reasons.  We don't want any
methods other than execute exposed to Javascript.  I also prefer this
approach because it is less prone to less catastrophic bugs than using
Java reflection.  We try and only use reflection when we have to.

On Wed, May 28, 2014 at 5:50 AM, Erik Jan de Wit ede...@redhat.com
wrote:

Hi,

When one is writing a plugin for android ATM the api that you have to

implement has a execute method that has the action as a string:

@Override
 public boolean execute(String action, JSONArray args,

CallbackContext callbackContext) throws JSONException {

 if (beep.equals(action)) {
 this.beep(args.getLong(0));
 callbackContext.success();
 return true;
 }
 return false;  // Returning false results in a MethodNotFound

error.

 }
When you have multiple actions this method gets very long, if you

compare this with iOS here you don’t need a method like this you could
‘just’ implement the method directly:

- (void)beep:(CDVInvokedUrlCommand*)command
 {
 CDVPluginResult* pluginResult =il;
 NSString* myarg =command.arguments objectAtIndex:0];

 if (myarg !=il) {
 pluginResult =CDVPluginResult

resultWithStatus:CDVCommandStatus_OK];

 } else {
 pluginResult =CDVPluginResult

resultWithStatus:CDVCommandStatus_ERROR messageAsString:@Arg was null];

 }
 [self.commandDelegate sendPluginResult:pluginResult

callbackId:command.callbackId];

 }
We could do the same thing for android if we use reflection, making the

API more similar and removing all the string test by the user. What do you
think?

Cheers,
 Erik Jan

Re: First stab at Next Steps article

[Terence M. Bandoian]

From a relative newcomer's point of view, should some distinction be 
made between plugins officially maintained by Apache Cordova and those 
that are not?


-Terence


On 4/30/2014 4:40 PM, Andrew Grieve wrote:

On Wed, Apr 30, 2014 at 5:28 PM, Josh Soref jso...@blackberry.com wrote:


Ray Camden wrote:

I had 3 hours here at the airport so I took at stab at writing content
for the Next Steps document. You can find (and edit) the document here:



https://docs.google.com/document/d/1uJ5qXqQxK2oh1eZPgMdYuhK2rQTB7QMHXUHbkc

omWgk/edit#

Personally, I favor ether pads / pirate pads.


The main thing missing now (imo) is the Upgrade section.
I think with that added - this is in a good place (at least initially).

Thoughts, opinions, etc?

I like it.


Any volunteers ready to write out the upgrade section?

I don't want to set up a Google account at work, but


FYI - you don't need an account to edit a doc that's made editable via
those with the link (as this one is).


1. Please don't mention WebSQL.
2. The offline/online event is not a great indicator, it's a hint, but it
can be misleading. People need to try a connection (XHR) to their
destination, if it works, great, if it doesn't that's it. If I'm in a
captive portal, or if I'm in an office, I can easily not have access to
your backend, even though I do have some form of network access.
3. For Debugging, on BlackBerry 10, you get web inspector out of the box.
https://developer.blackberry.com/html5/documentation/v2_0/enabling_web_insp
ector.html
https://developer.blackberry.com/html5/documentation/v2_0/debugging_using_w
eb_inspector.html

4. I think we decided to favor stack overflow over google groups
5. s/you simulator the accelerometer to test shake events/you simulate the
accelerometer to test shake events/
— this last one means you should introduce the document to WinWord and ask
it for an opinion :).

Re: Some pain points from our users :'(

[Terence M. Bandoian]

For what it's worth, the biggest problem I've had in upgrading is with 
'phonegap plugin add plugin'.  The native code gets copied but 
cordova_plugins.js doesn't get updated and the plugin JS isn't wrapped 
in a call to cordova.define.  In a couple of Stack Overflow posts, 
running 'phonegap build platform' after adding a plugin is suggested 
but I don't see that documented in the Phonegap docs.  Plus, that 
overwrites the www directory so it has to be copied beforehand which is 
troublesome if there are platform-specific customizations.  (Is that the 
only time the outer www is used?)  In addition, I didn't find 
documentation for the contents of cordova_plugins.js or the linkage 
between it and the plugin JS so I wasn't sure what was required and had 
to piece that together on my own.  In the end, I manually updated 
cordova_plugin.js and the plugin JS files which is way more hairs than I 
think was intended.


Overall, I still think Cordova is great framework but that improved 
documentation would go a long way towards making that more apparent.


-Terence


On 4/28/2014 2:15 PM, Michal Mocny wrote:

s/mailing list/distribution list/


On Mon, Apr 28, 2014 at 3:14 PM, Michal Mocny mmo...@chromium.org wrote:


I think this particular users' frustration is not addressable (and his
feedback in places is just annoying:  you work for X and I demand that you
should have the money to do everything for me).
He hasn't maintained his project for 2 years, hasn't read our docs, hasn't
written tests to guard against platform assumptions, and expects to update
everything in a few hours.
There are a few issues he got hit with (plugin authoring with the CLI is a
pain in the butt, 3.4 release plugin docs issue), but generally its
probably not worth putting to much weight into it.

More broadly, though, perhaps we should acknowledge that we will never
catch all issues with releases and try to find ways to incentivize the
community to help test out RC's for us?  Perhaps a dedicated mailing list
for known developers who stay bleeding edge that we email as part of
starting the release vote process / at the end of [DISCUSS] thread?

-Michal


On Mon, Apr 28, 2014 at 2:54 PM, Shazron shaz...@gmail.com wrote:


We come with a (framework) developer's perspective, thus an echo chamber.
The comments may or may not be fair but the users do encounter pain, and I
think it does help in identifying issues we missed (reading from the list
overall). Canary in the coal mine, etc.

Filing issues etc ideal, but some, for whatever reason, do not like that
type of forum, but still choose the Google Groups.




On Mon, Apr 28, 2014 at 11:44 AM, Brian LeRoux b...@brian.io wrote:


I feel the comments there are not really constructive or fair. Cordova
changes too much? Sorry, static code means bitrot aka abandonware.

We work on Cordova because we are improving it for the many thousands of
our users whom appreciate that. I don't need to tell you guys that but

1.8

was a mess compared to 3.x and if you are only updating YOUR userland
source once every 2 years and you don't expect it to be come with
problems?! The bugs found usually are not introduced by us but with

Xcode,

iOS, or Android and we are FIXING those things with updates.

Docs are a problem but as they say patches welcome. This is the sort of
entitled complaint that lead me off that list.



On Mon, Apr 28, 2014 at 11:30 AM, Shazron shaz...@gmail.com wrote:


See:

https://groups.google.com/d/msg/phonegap/II0qo-dSFWs/Fj8jkemGSbUJ

Hangout on 4/15 @ 4:00 EST

[Terence M. Bandoian]

On 4/15/2014 3:07 PM, Andrew Grieve wrote:

View-only: http://youtu.be/5lR1a8V_po0

On Tue, Apr 15, 2014 at 12:01 PM, Andrew Grieve agri...@chromium.org wrote:

Link to join if you want to talk:
https://plus.google.com/hangouts/_/hoaevent/AP36tYciQ2qhQzBbNbvbX-G0tKN9YleIV754KNT2CULwdybs72KN9w?authuser=0hl=en-GB

View-only link will come in a moment.




Has a recording of this hangout been posted anywhere?

-Terence Bandoian

Re: Hangout on 4/15 @ 4:00 EST

[Terence M. Bandoian]

Duh.  Works for me as well.

Thanks.

-Terence


On 4/17/2014 5:36 PM, Michal Mocny wrote:

The link is attached to the email you replied to:
http://youtu.be/5lR1a8V_po0

(works for me, at least.)


On Thu, Apr 17, 2014 at 6:07 PM, Terence M. Bandoian tere...@tmbsw.comwrote:


On 4/15/2014 3:07 PM, Andrew Grieve wrote:


View-only: http://youtu.be/5lR1a8V_po0

On Tue, Apr 15, 2014 at 12:01 PM, Andrew Grieve agri...@chromium.org
wrote:


Link to join if you want to talk:
https://plus.google.com/hangouts/_/hoaevent/AP36tYciQ2qhQzBbNbvbX-
G0tKN9YleIV754KNT2CULwdybs72KN9w?authuser=0hl=en-GB

View-only link will come in a moment.



Has a recording of this hangout been posted anywhere?

-Terence Bandoian

Re: Introduction and Possible Contribution

[Terence M. Bandoian]

Thanks, Andrew.  They looked distinct to me so I went ahead and sent the 
pull request.  The comment should read something like Allows for one 
set of iPad launch images for iOS 7+ and another for pre-iOS 7.


-Terence


On 3/17/2014 10:53 PM, Andrew Grieve wrote:

Hi Terence!

Sounds like a smart improvement. Would definitely welcome a patch for this.
:)

Found there's a similar sounding pull request here:
https://github.com/apache/cordova-plugin-splashscreen/pull/13. Not sure how
much they overlap.

Andrew




On Fri, Mar 14, 2014 at 5:29 PM, Terence M. Bandoian tere...@tmbsw.comwrote:


First, thanks for all the great work.  I'm fairly new to Cordova but have
quite a bit of experience otherwise and have so far found it to be an
excellent framework for mobile app development.

In a recent iPad project, I added a section of code to the updateImage
method of the splash screen plugin that uses the UILaunchImages array in
the main bundle to support different sized launch images for iOS 7.
  UILaunchImages is automatically generated by Xcode according to the images
selected in the Launch Images section of the General settings.  If it would
be useful, I would be happy to submit a pull request and contribute the
modification to the project.  My ICLA is on file with ASF.

Thanks again.

-Terence Bandoian

Introduction and Possible Contribution

[Terence M. Bandoian]

First, thanks for all the great work.  I'm fairly new to Cordova but 
have quite a bit of experience otherwise and have so far found it to be 
an excellent framework for mobile app development.


In a recent iPad project, I added a section of code to the updateImage 
method of the splash screen plugin that uses the UILaunchImages array in 
the main bundle to support different sized launch images for iOS 7.  
UILaunchImages is automatically generated by Xcode according to the 
images selected in the Launch Images section of the General settings.  
If it would be useful, I would be happy to submit a pull request and 
contribute the modification to the project.  My ICLA is on file with ASF.


Thanks again.

-Terence Bandoian