Re: [Vote] 5.0.0 Windows Release

[Karen Tran]

I vote +1

- Tested  tag functionality is copying or referencing if
reference attribute is set
- Tested compatibility with Visual Studio
- Ran automated tests

On Thu, Feb 9, 2017 at 9:24 AM, Vladimir Kotikov (Akvelon) <
v-vlk...@microsoft.com.invalid> wrote:

> I vote +1
>
> - Verified licenses and license headers
> - Ran automates tests
> - Verified archive
> - Verified tag
>
> -
> Best regards, Vladimir
>
>
> On 2/9/17, 09:57, "alsoro...@apache.org"  wrote:
>
> I vote +1.
>
> * Verified archives via `coho verify-archive`
> * Verified tags manually
> * Verified that blank app creates correctly with platform
> * Verified that blank app can be successfully built and ran
> * Verified that platform can be updated from previous version
> * Verified compatibility with core plugins
> * Verified release notes
> * Verified version
> * Verified line breaks
> * Verified compatibility with Visual Studio
>
> -- Alexander Sorokin
>
> -Original Message-
> From: dase...@apache.org [mailto:dase...@apache.org]
> Sent: Wednesday, February 8, 2017 8:20 PM
> To: dev@cordova.apache.org
> Subject: [Vote] 5.0.0 Windows Release
>
> Please review and vote on this 5.0.0 Windows Release
>
> by replying to this email (and keep discussion on the DISCUSS thread)
>
>
>
> Release issue:
> https://na01.safelinks.protection.outlook.com/?url=
> https%3A%2F%2Fissues.apac
> he.org%2Fjira%2Fbrowse%2FCB-12404=02%7C01%7Cv-alsoro%
> 40microsoft.com%7C
> 27147ccdfdcc4e8d12ab08d45046afec%7C72f988bf86f141af91ab2d7cd011
> db47%7C1%7C0%
> 7C636221711911814136=Q%2BsHad7YDUJ7gaAe4efeD1d1ntNWQN
> Z6vWPTB9otP6A%3D&
> reserved=0
>
>
>
> The archive has been published to dist/dev:
>
> https://na01.safelinks.protection.outlook.com/?url=
> https%3A%2F%2Fdist.apache
> .org%2Frepos%2Fdist%2Fdev%2Fcordova%2FCB-12404%2F=
> 02%7C01%7Cv-alsoro%40
> microsoft.com%7C27147ccdfdcc4e8d12ab08d45046afec%
> 7C72f988bf86f141af91ab2d7cd
> 011db47%7C1%7C0%7C636221711911814136=
> EBwPD3j4cb9idteUka7BZzpVVPgXZfkE9
> NhTnRbsuDk%3D=0
>
>
>
> The package was published from its corresponding git tag:
>
> cordova-windows: 5.0.0 (75d7bcf01e)
>
>
>
> Note that you can test it out via:
>
>
>
> cordova platform add
> https://na01.safelinks.protection.outlook.com/?url=
> https%3A%2F%2Fgithub.com%
> 2Fapache%2Fcordova-windows%235.0.0=02%7C01%7Cv-alsoro%
> 40microsoft.com%7
> C27147ccdfdcc4e8d12ab08d45046afec%7C72f988bf86f141af91ab2d7cd011
> db47%7C1%7C0
> %7C636221711911814136=2nyElr3rLRACU1mp%2B9CeCepjep8%
> 2BTERrLaZWCZSdX%2B
> 0%3D=0
>
>
>
> Upon a successful vote I will upload the archive to dist/, publish it
> to
> npm, and post the blog post.
>
>
>
> Voting guidelines:
> https://na01.safelinks.protection.outlook.com/?url=
> https%3A%2F%2Fgithub.com%
> 2Fapache%2Fcordova-coho%2Fblob%2Fmaster%2Fdocs%
> 2Frelease-voting.md=02%7
> C01%7Cv-alsoro%40microsoft.com%7C27147ccdfdcc4e8d12ab08d45046
> afec%7C72f988bf
> 86f141af91ab2d7cd011db47%7C1%7C0%7C636221711911814136&
> sdata=wZ3BZYdWUF7%2BB0
> PzVrlR%2B1dQAd0LcsL%2Bxa9nQXqY2wo%3D=0
>
>
>
> Voting will go on for a minimum of 48 hours.
>
>
>
> I vote +1:
>
> * Ran coho audit-license-headers over the relevant repos
>
> * Ran coho check-license to ensure all dependencies and
> subdependencies have
> Apache-compatible licenses
>
> * Ensured continuous build was green when repo was tagged
>
> * Ensured that all tests pass
>
> * Created, built and ran mobilespec app
>
> * Tested create and update scenarios via platform scripts and
> cordova-cli
>
>
>
> Please let me know if you have any questions or considerations.
>
>
>
> Best regards,
>
> Sergey Shakhnazarov.
>
>
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>
>
>
>

Re: [DISCUSS] Cordova-Windows Release

[Karen Tran]

+1 on cordova-windows release

On Fri, Jan 27, 2017 at 6:26 AM, julio cesar sanchez  wrote:

> Does anyone have any reason to delay a cordova-android platform release?
>
> Yeah, we just released cordova-android 6.1.2 :P
>
> +1 to releasing cordova-windows
>
>
>
>
>
> 2017-01-27 12:16 GMT+01:00 Sergey Shakhnazarov :
>
> > Does anyone have any reason to delay a cordova-android platform release?
> > Any outstanding patches to land?
> > Here's the release notes draft:
> > ### 5.0.0 (Jan 27, 2017)
> > * Remove duplicate logic after upgrading cordova-common
> > * [CB-12163](https://issues.apache.org/jira/browse/CB-12163) Add
> > resource-file reference functionality through a flag
> > * [CB-12163](https://issues.apache.org/jira/browse/CB-12163) Make
> > resource-file copy files again
> > * Upgrade cordova-common to 2.0.0
> > * [CB-12298](https://issues.apache.org/jira/browse/CB-12298) [Windows]
> > bundle.appxupload not generated for Windows 10 target
> > * [CB-12189](https://issues.apache.org/jira/browse/CB-12189) Add
> > support for WinMD and DLL combination
> > * [CB-12238](https://issues.apache.org/jira/browse/CB-12238) [Windows]
> > Colorize titlebar to match splash bg color
> > * [CB-11177](https://issues.apache.org/jira/browse/CB-11177)
> > SplashScreen gets shifted on Windows devices with soft navbar
> > * [CB-12239](https://issues.apache.org/jira/browse/CB-12239) Add
> > buildFlag option similar to iOS
> > * [CB-12193](https://issues.apache.org/jira/browse/CB-12193)
> > cordova.js crashes windows app if there is no CoreWindow Also made
> > confighelper to load after WinJS as it depends on it
> > * [CB-11751](https://issues.apache.org/jira/browse/CB-11751)
> > 'extendedSplashScreen' is undefined
> > * [CB-12192](https://issues.apache.org/jira/browse/CB-12192) - No
> > SplashScreen on Windows when content.src is subpage
> > * [CB-9287](https://issues.apache.org/jira/browse/CB-9287) Not enough
> > Icons and Splashscreens for Windows 8.1 and Windows Phone 8.1
> > * Do not ignore already prefixed capabilities at plugin add/rm
> > * Fix pattern for extracting capabilities names
> > * [CB-12142](https://issues.apache.org/jira/browse/CB-12142) Move
> > windows-specific logic from cordova-common
> > * [CB-12147](https://issues.apache.org/jira/browse/CB-12147) (windows)
> > Fix typo in verbose output
> > * [CB-12124](https://issues.apache.org/jira/browse/CB-12124) Make
> > available device capabilities in package.windows10.appxmanifest
> > * [CB-12071](https://issues.apache.org/jira/browse/CB-12071) Fix for
> > [CB-11825](https://issues.apache.org/jira/browse/CB-11825) breaks
> > usage of InProcessServer in Cordova Windows
> > * [CB-12036](https://issues.apache.org/jira/browse/CB-12036) Fix
> > setSplashBgColor exception when no splashscreen is found
> >
> > If not, I will start the release tomorrow.
> >
> > Best regards,
> >
> > Sergey Shakhnazarov,
> >
> > Akvelon developer.
> >
>

Re: [DISCUSS] tools release

[Karen Tran]

+1

On Mon, Jan 16, 2017 at 6:54 AM,  wrote:

> Hi guys,
>
> What is the status of Tools Release?
> We can handle it as we need to release Windows platform with
> cordova-common updates but we need to know the exact list of things to be
> included in it.
>
> Please let me know if you have any questions or considerations.
>
> Best regards,
> Sergey Shakhnazarov,
> Akvelon developer.
>
> -Original Message-
> From: Vladimir Kotikov (Akvelon) [mailto:v-vlk...@microsoft.com]
> Sent: Wednesday, December 21, 2016 15:46
> To: dev@cordova.apache.org
> Subject: Re: [DISCUSS] tools release
>
> +1
>
> We’re specifically interested in these three PRs:
> - https://na01.safelinks.protection.outlook.com/?url=
> https%3A%2F%2Fgithub.com%2Fapache%2Fcordova-lib%2Fpull%
> 2F505=02%7C01%7Cv-seshak%40microsoft.com%
> 7Ce8e7ef34878d497246e008d4299f662b%7C72f988bf86f141af91ab2d7cd011
> db47%7C1%7C0%7C636179211969896647=HkZ%2FmT9ZCcsvLyP3GuqtD%
> 2FZQxyhybaiYA%2BLCrYjBVaU%3D=0
> - https://na01.safelinks.protection.outlook.com/?url=
> https%3A%2F%2Fgithub.com%2Fapache%2Fcordova-lib%2Fpull%
> 2F509=02%7C01%7Cv-seshak%40microsoft.com%
> 7Ce8e7ef34878d497246e008d4299f662b%7C72f988bf86f141af91ab2d7cd011
> db47%7C1%7C0%7C636179211969896647=Aj7muzsOli2qEnuPHyintdelemmsZo
> lLlHcTp%2FB9U5E%3D=0
> - https://na01.safelinks.protection.outlook.com/?url=
> https%3A%2F%2Fgithub.com%2Fapache%2Fcordova-lib%2Fpull%
> 2F513=02%7C01%7Cv-seshak%40microsoft.com%
> 7Ce8e7ef34878d497246e008d4299f662b%7C72f988bf86f141af91ab2d7cd011
> db47%7C1%7C0%7C636179211969896647=J3huQ2NR7Zq9JbVsGbzcSqCIsPmGP%
> 2FIgRJx8VKxuha8%3D=0
>
> Notice that the first one contains a change that might break plugins that
> use  to modify appxmanifest files on Windows, so I think there
> should be a major version bump for cordova-common.
>
> -
> Best regards, Vladimir
>
>
> On 12/21/16, 03:19, "Steven Gill"  wrote:
>
> Adobe starts shutdown tomorrow until Jan 3 so adobe committers will be
> away
> during that span.
>
> I agree we need a release but I'm fine waiting until new year to start
> it.
> There are a few PRs that would be nice to get in. Our CI for
> cordova-lib
> has been failing for a while due to cordova-android@6.1.0. Android
> needs a
> 6.1.1 release too to fix that (or we update the tests to use nightly or
> github)
>
>
>
> On Tue, Dec 20, 2016 at 2:51 PM, julio cesar sanchez <
> jcesarmob...@gmail.com
> > wrote:
>
> > Should we do a tools release?
> >
> > As we released cordova-android 6.1.0 and it was a minor bump, the
> current
> > CLI still picks 6.0.0. There is a lot of people hitting the icons
> problem
> > as they don't read the blog and don't know that 6.1.0 is available.
> > Also, there is another problem when adding browser platform that
> shows an
> > "Error loading cordova-browser" message, but the platform is added
> > correctly. This has been also fixed.
> >
> >
> > Not related to the release, but as we have a way of showing an
> informative
> > message that tells you that you are not using latest CLI, could we
> do the
> > same to tell that you are not adding the latest platform available?
> >
>
>
>  B�CB�
> � [��X��ܚX�K  K[XZ[
> �  ]�][��X��ܚX�P �ܙ ݘK�\ X� K�ܙ�B��܈ Y  ] [ۘ[  ��[X[� �  K[XZ[
> �  ]�Z [   �ܙ ݘK�\ X� K�ܙ�B
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>
>

Re: [Vote] 6.1.1 Android Release

[Karen Tran]

I vote +1:
* Created and ran a plain app
* Ran app from Android Studio
* Ran mobilespec

On Tue, Jan 3, 2017 at 9:03 PM, Steven Gill  wrote:

> Please review and vote on this 6.1.1 Android Release
> by replying to this email (and keep discussion on the DISCUSS thread)
>
> Release issue: https://issues.apache.org/jira/browse/CB-12314
>
> The archive has been published to
> dist/dev:https://dist.apache.org/repos/dist/dev/cordova/CB-12314
>
>
> The package was published from its corresponding git tag:
> cordova-android: 6.1.1 (96457effbc)
>
> Note that you can test it out via:
>
> cordova platform add https://github.com/apache/cordova-android#6.1.1
>
> Upon a successful vote I will upload the archive to dist/, publish it
> to npm, and post the blog post.
>
> Voting guidelines:
> https://github.com/apache/cordova-coho/blob/master/docs/release-voting.md
>
> Voting will go on for a minimum of 48 hours.
>
> I vote +1:
> * Ran coho audit-license-headers over the relevant repos
> * Ran coho check-license to ensure all dependencies and
> subdependencies have Apache-compatible licenses
> * Ran mobilespec
>

Re: [DISCUSSION] Windows tag, what should it be doing?

[Karen Tran]

No problem. I'll work on getting the copy functionality and reference flag
in and then I can take a look at your suggestion. Sounds like a useful
feature to me.

On Tue, Dec 13, 2016 at 3:36 AM, Котиков Владимир <
kotikov.vladi...@gmail.com> wrote:

> Hey Karen, sorry for last minute response.
>
> I’m _personally_ +1 for getting back the original behavior (i.e. copy
> instead of referencing the original files), I only think that we’d to make
> sure that the case, described in https://github.com/apache/
> cordova-windows/pull/139 still works with that new flag (I can help with
> verification).
>
> Also, nobody has asked if this would be a reason for a major version
> change? Technically we’re going to break the things, so yes, but from the
> other side it’s kind of regression and unexpected change that needs to be
> fixed. IMO it should be at least minor bump, since we’re going to add a new
> flag
>
> + another suggestion about implementation: IMO the main confusing point
> with the original behavior (copying and then referencing copied file) was
> that if you have two tags:
>
> 
> 
>
> the second one would silently overwrite the first one and the user will
> get some cryptic errors at _runtime_. I propose to make copying logic a bit
> smarter and at least emit a warning when one resource would overwrite
> another and suggest using a flag to add a reference, rather than copy files.
>
>
>
> On 12/12/16, 20:23, "Karen Tran" <ktop...@gmail.com> wrote:
>
> Does anyone have any other objections?
> Otherwise I'll proceed to work on this tomorrow.
>
> On Thu, Dec 8, 2016 at 8:03 PM, Shazron <shaz...@gmail.com> wrote:
>
> > +1 sounds good
> >
> > On Thu, Dec 8, 2016 at 4:36 PM, Karen Tran <ktop...@gmail.com>
> wrote:
> >
> > > I dug up the old pull request for this behavior change (
> > > https://na01.safelinks.protection.outlook.com/?url=
> https%3A%2F%2Fgithub.com%2Fapache%2Fcordova-windows%
> 2Fpull%2F139=02%7C01%7Cv-vlkoti%40microsoft.com%
> 7Cfd5830ed12474774b88d08d422b3a5de%7C72f988bf86f141af91ab2d7cd011
> db47%7C1%7C0%7C636171602363520388=QYSHbcwPFrPlhItNTNMHYifiuzXo5u
> 9nzOt3Z0tuZ%2FQ%3D=0) and it seems like
> > the
> > > main goal for the change was to be able to have .dll files
> specific to
> > > different architectures without having different target locations
> for
> > each
> > > of them and make the .dll files visible in Visual Studio so that
> Visual
> > > Studio can reference them.
> > > ^Correct me if I'm wrong here...
> > >
> > > I tested the following two sets and now have a better
> understanding of
> > why
> > > this behavior was added, but I'm not entirely sure why it had to
> replace
> > > the copy in the first place as opposed to adding a flag to do
> referencing
> > > instead of copy. Having both behavior in resource-file is probably
> okay
> > > since they are kind of similar.
> > >
> > > Set 1.
> > > 
> > > 
> > > - With copy, this behaves the exact same as the referencing
> behavior.
> > > - The only difference between each behavior is the path where
> Visual
> > Studio
> > > will point to the file, copy will point to the target and
> reference will
> > > point to src
> > >
> > > Set 2.
> > > 
> > > 
> > > - With copy, only the x64 foo.dll will be used since the second
> > >  would overwrite the first one. In Visual Studio,
> the
> > > foo.dll when targeting x86 or x64 will point to the same x64
> foo.dll. So
> > > this is the issue with copy for this specific case.
> > > - With referencing, Visual Studio will properly reference the
> correct
> > > foo.dll because it's pointing to the src path and there is no
> overwriting
> > > here.
> > >
> > > I will propose that resource-file should default to copy and the
> > reference
> > > behavior should be set by a flag. This is what it should have been
> when
> > the
> > > behavior was changed, so I think it's worth making the switch back
> to
> > copy
> > > even though it will be breaking a few users (because right now it
> might
> > > unknowingly be breaking more users who have long since been
> expecting
> > > resource-file to copy; it was never documented that resource-file
> had
> > > chan

Re: [DISCUSSION] Windows tag, what should it be doing?

[Karen Tran]

Does anyone have any other objections?
Otherwise I'll proceed to work on this tomorrow.

On Thu, Dec 8, 2016 at 8:03 PM, Shazron <shaz...@gmail.com> wrote:

> +1 sounds good
>
> On Thu, Dec 8, 2016 at 4:36 PM, Karen Tran <ktop...@gmail.com> wrote:
>
> > I dug up the old pull request for this behavior change (
> > https://github.com/apache/cordova-windows/pull/139) and it seems like
> the
> > main goal for the change was to be able to have .dll files specific to
> > different architectures without having different target locations for
> each
> > of them and make the .dll files visible in Visual Studio so that Visual
> > Studio can reference them.
> > ^Correct me if I'm wrong here...
> >
> > I tested the following two sets and now have a better understanding of
> why
> > this behavior was added, but I'm not entirely sure why it had to replace
> > the copy in the first place as opposed to adding a flag to do referencing
> > instead of copy. Having both behavior in resource-file is probably okay
> > since they are kind of similar.
> >
> > Set 1.
> > 
> > 
> > - With copy, this behaves the exact same as the referencing behavior.
> > - The only difference between each behavior is the path where Visual
> Studio
> > will point to the file, copy will point to the target and reference will
> > point to src
> >
> > Set 2.
> > 
> > 
> > - With copy, only the x64 foo.dll will be used since the second
> >  would overwrite the first one. In Visual Studio, the
> > foo.dll when targeting x86 or x64 will point to the same x64 foo.dll. So
> > this is the issue with copy for this specific case.
> > - With referencing, Visual Studio will properly reference the correct
> > foo.dll because it's pointing to the src path and there is no overwriting
> > here.
> >
> > I will propose that resource-file should default to copy and the
> reference
> > behavior should be set by a flag. This is what it should have been when
> the
> > behavior was changed, so I think it's worth making the switch back to
> copy
> > even though it will be breaking a few users (because right now it might
> > unknowingly be breaking more users who have long since been expecting
> > resource-file to copy; it was never documented that resource-file had
> > changed at all). Resource-file wasn't intended for .dll, but for actual
> > resources like json, images, xml, and my case properties files. So this
> is
> > a big issue if some of these resources aren't available to the app at run
> > time.
> > <https://github.com/ktop/cordova-windows/tree/cb12163>
> >
> > TL;DR
> > I propose setting copy as default and the reference behavior with a flag
> > because this is what it should have been in the first place.
> >
> > On Wed, Dec 7, 2016 at 5:58 PM, Karen Tran <ktop...@gmail.com> wrote:
> >
> > > Sorry I missed this, it was in my spam folder.
> > >
> > > I think the general consensus is that  should definitely
> > > have the copy function added back. Not sure if it was clear if we came
> > to a
> > > conclusion on whether it should be default behavior though.
> > >
> > > As for what to do for the reference behavior, I think the easy route is
> > to
> > > do what you suggested Tim and keep the current behavior as the default
> > and
> > > have the copy be an attribute users can set. Intuitively though, I
> think
> > > resource-file should default to copy as expected just like other
> > platforms,
> > > and any other behavior can be handled with attribute flags or moved to
> > > another more appropriate tag.
> > >
> > > I would lean towards the second option because it makes more sense to
> me
> > > as a plugin developer because all  tags do a copy. I know it
> > > would break existing plugins that depend on the current behavior, but I
> > can
> > > say the same for resource-file being changed in the first place and
> never
> > > documented nor mentioned in any blog release (my plugin is currently
> > > broken). I don't know if many developers are even aware that it was
> > changed
> > > besides the contributor. It's been in cordova-windows since v4.4.0.
> > >
> > > So this falls back on my initial two questions I asked:
> > > 1. What should be the default behavior of  tag? Should
> it
> > > simply be copy resources as it was originally intended to, or should it
> > be
> > > doing what it is now, which is making a refe

Re: [DISCUSSION] Windows tag, what should it be doing?

[Karen Tran]

I dug up the old pull request for this behavior change (
https://github.com/apache/cordova-windows/pull/139) and it seems like the
main goal for the change was to be able to have .dll files specific to
different architectures without having different target locations for each
of them and make the .dll files visible in Visual Studio so that Visual
Studio can reference them.
^Correct me if I'm wrong here...

I tested the following two sets and now have a better understanding of why
this behavior was added, but I'm not entirely sure why it had to replace
the copy in the first place as opposed to adding a flag to do referencing
instead of copy. Having both behavior in resource-file is probably okay
since they are kind of similar.

Set 1.


- With copy, this behaves the exact same as the referencing behavior.
- The only difference between each behavior is the path where Visual Studio
will point to the file, copy will point to the target and reference will
point to src

Set 2.


- With copy, only the x64 foo.dll will be used since the second
 would overwrite the first one. In Visual Studio, the
foo.dll when targeting x86 or x64 will point to the same x64 foo.dll. So
this is the issue with copy for this specific case.
- With referencing, Visual Studio will properly reference the correct
foo.dll because it's pointing to the src path and there is no overwriting
here.

I will propose that resource-file should default to copy and the reference
behavior should be set by a flag. This is what it should have been when the
behavior was changed, so I think it's worth making the switch back to copy
even though it will be breaking a few users (because right now it might
unknowingly be breaking more users who have long since been expecting
resource-file to copy; it was never documented that resource-file had
changed at all). Resource-file wasn't intended for .dll, but for actual
resources like json, images, xml, and my case properties files. So this is
a big issue if some of these resources aren't available to the app at run
time.
<https://github.com/ktop/cordova-windows/tree/cb12163>

TL;DR
I propose setting copy as default and the reference behavior with a flag
because this is what it should have been in the first place.

On Wed, Dec 7, 2016 at 5:58 PM, Karen Tran <ktop...@gmail.com> wrote:

> Sorry I missed this, it was in my spam folder.
>
> I think the general consensus is that  should definitely
> have the copy function added back. Not sure if it was clear if we came to a
> conclusion on whether it should be default behavior though.
>
> As for what to do for the reference behavior, I think the easy route is to
> do what you suggested Tim and keep the current behavior as the default and
> have the copy be an attribute users can set. Intuitively though, I think
> resource-file should default to copy as expected just like other platforms,
> and any other behavior can be handled with attribute flags or moved to
> another more appropriate tag.
>
> I would lean towards the second option because it makes more sense to me
> as a plugin developer because all  tags do a copy. I know it
> would break existing plugins that depend on the current behavior, but I can
> say the same for resource-file being changed in the first place and never
> documented nor mentioned in any blog release (my plugin is currently
> broken). I don't know if many developers are even aware that it was changed
> besides the contributor. It's been in cordova-windows since v4.4.0.
>
> So this falls back on my initial two questions I asked:
> 1. What should be the default behavior of  tag? Should it
> simply be copy resources as it was originally intended to, or should it be
> doing what it is now, which is making a reference to the resource files.
> 2. Should  tag handle both functionalities, or should one
> be separated out into another tag?
>
>
> On Fri, Dec 2, 2016 at 9:31 PM, Tim Barham <tim.bar...@microsoft.com>
> wrote:
>
>> It seems to me it would be bad form to simply change the default behavior
>> back to copy, if that will break existing plugins that rely on the current
>> behavior. While it would be inconsistent with other platforms, perhaps we
>> should leave the current default behavior as-is and add an attribute to
>> specify copy behavior? And then document the discrepancy.
>>
>> Otherwise we shouldn't do it until we know framework can work as an
>> alternative, but will plugin developers be able to implement their plugin
>> in such a way that it works for both cases? And how will they know they
>> need to make this change?
>>
>> -Original Message-
>> From: Karen Tran [mailto:ktop...@gmail.com]
>> Sent: Saturday, December 3, 2016 8:04 AM
>> To: dev@cordova.apache.org
>> Subject: Re: [DISCUSSION] Windows  tag, what sho

Re: [DISCUSSION] Windows tag, what should it be doing?

[Karen Tran]

Sorry I missed this, it was in my spam folder.

I think the general consensus is that  should definitely
have the copy function added back. Not sure if it was clear if we came to a
conclusion on whether it should be default behavior though.

As for what to do for the reference behavior, I think the easy route is to
do what you suggested Tim and keep the current behavior as the default and
have the copy be an attribute users can set. Intuitively though, I think
resource-file should default to copy as expected just like other platforms,
and any other behavior can be handled with attribute flags or moved to
another more appropriate tag.

I would lean towards the second option because it makes more sense to me as
a plugin developer because all  tags do a copy. I know it would
break existing plugins that depend on the current behavior, but I can say
the same for resource-file being changed in the first place and never
documented nor mentioned in any blog release (my plugin is currently
broken). I don't know if many developers are even aware that it was changed
besides the contributor. It's been in cordova-windows since v4.4.0.

So this falls back on my initial two questions I asked:
1. What should be the default behavior of  tag? Should it
simply be copy resources as it was originally intended to, or should it be
doing what it is now, which is making a reference to the resource files.
2. Should  tag handle both functionalities, or should one be
separated out into another tag?


On Fri, Dec 2, 2016 at 9:31 PM, Tim Barham <tim.bar...@microsoft.com> wrote:

> It seems to me it would be bad form to simply change the default behavior
> back to copy, if that will break existing plugins that rely on the current
> behavior. While it would be inconsistent with other platforms, perhaps we
> should leave the current default behavior as-is and add an attribute to
> specify copy behavior? And then document the discrepancy.
>
> Otherwise we shouldn't do it until we know framework can work as an
> alternative, but will plugin developers be able to implement their plugin
> in such a way that it works for both cases? And how will they know they
> need to make this change?
>
> -----Original Message-
> From: Karen Tran [mailto:ktop...@gmail.com]
> Sent: Saturday, December 3, 2016 8:04 AM
> To: dev@cordova.apache.org
> Subject: Re: [DISCUSSION] Windows  tag, what should it be
> doing?
>
> Thanks for the input everyone. resource-file definitely makes better sense
> to copy files. I can work on getting the copy functionality back into
> resource-file some time next week.
>
> Sidenote:
> The issue with the `framework` tag from the contributor to this change
> said, from CB-10326 <https://na01.safelinks.protection.outlook.com/?url=
> https%3A%2F%2Fissues.apache.org%2Fjira%2Fbrowse%2FCB-
> 10326=02%7C01%7CTim.Barham%40microsoft.com%
> 7C8aad7996a77c4232984008d41aff194c%7C72f988bf86f141af91ab2d7cd011
> db47%7C1%7C0%7C636163130331524841=xMO4L%
> 2B2JBIy5LERs2JJeT6tjaJweSOfX8HAb9kdTvfU%3D=0> "When I'm using
> framework VS14 complains that my dll's don't have a manifest ".
> Which is why he opted to use resource-file tag instead of framework tag.
>
> I'm not sure if framework tag has since updated to handle this, otherwise
> like Cesar's suggestion we can add something to the framework tag to handle
> this use case of .dll files without a manifest.
>
>
> On Fri, Dec 2, 2016 at 3:34 PM, Shazron <shaz...@gmail.com> wrote:
>
> > I fully expect resource-file to copy things over, as advertised in the
> > docs.
> >
> > Somewhat related issue on iOS:
> > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissue
> > s.apache.org%2Fjira%2Fbrowse%2FCB-12009=02%7C01%7CTim.Barham%40mi
> > crosoft.com%7C8aad7996a77c4232984008d41aff194c%7C72f988bf86f141af91ab2
> > d7cd011db47%7C1%7C0%7C636163130331524841=UoNsuqqH3EYZjTSZgDQkv1q
> > 49XuAGwoUXyWp8OfxjyI%3D=0
> >
> > On Fri, Dec 2, 2016 at 11:27 AM, Kerri Shotts <kerrisho...@gmail.com>
> > wrote:
> >
> > > Interesting; if I were configuring a project, I’d be pretty
> > > surprised
> > that
> > > resource-file didn’t copy my file over. I prefer the path of least
> > surprise
> > > here, so I’d think that resource-file should copy files (if we have
> > > to
> > keep
> > > the existing method, maybe an attribute to switch?). BUT, I’d also
> > > prefer to keep things simpler, so I’d lean to using  for
> > > things like linking to DLLs and  for copying
> > > resources to the project (that don’t fit into other categories).
> > >
> > > So, +1 for @jcesar’s suggestion.
> > >
> > >
> > > > On Dec 2, 2016, at 02:26, julio ces

Re: [DISCUSSION] Windows tag, what should it be doing?

[Karen Tran]

Thanks for the input everyone. resource-file definitely makes better sense
to copy files. I can work on getting the copy functionality back into
resource-file some time next week.

Sidenote:
The issue with the `framework` tag from the contributor to this change
said, from CB-10326 <https://issues.apache.org/jira/browse/CB-10326> "When
I'm using framework VS14 complains that my dll's don't have a manifest ".
Which is why he opted to use resource-file tag instead of framework tag.

I'm not sure if framework tag has since updated to handle this, otherwise
like Cesar's suggestion we can add something to the framework tag to handle
this use case of .dll files without a manifest.


On Fri, Dec 2, 2016 at 3:34 PM, Shazron <shaz...@gmail.com> wrote:

> I fully expect resource-file to copy things over, as advertised in the
> docs.
>
> Somewhat related issue on iOS:
> https://issues.apache.org/jira/browse/CB-12009
>
> On Fri, Dec 2, 2016 at 11:27 AM, Kerri Shotts <kerrisho...@gmail.com>
> wrote:
>
> > Interesting; if I were configuring a project, I’d be pretty surprised
> that
> > resource-file didn’t copy my file over. I prefer the path of least
> surprise
> > here, so I’d think that resource-file should copy files (if we have to
> keep
> > the existing method, maybe an attribute to switch?). BUT, I’d also prefer
> > to keep things simpler, so I’d lean to using  for things like
> > linking to DLLs and  for copying resources to the project
> > (that don’t fit into other categories).
> >
> > So, +1 for @jcesar’s suggestion.
> >
> >
> > > On Dec 2, 2016, at 02:26, julio cesar sanchez <jcesarmob...@gmail.com>
> > wrote:
> > >
> > > We have the framework tag for the .dll files, so I think the
> > resource-file
> > > should copy as the other platforms do.
> > > If the framework tag is not working as expected, we can change the
> > > behaviour on windows to work as needed.
> > >
> > >
> > > 2016-12-02 6:56 GMT+01:00 Jesse <purplecabb...@gmail.com>:
> > >
> > >> Hi Karen,
> > >>
> > >> I am not sure which is the best approach, but I agree that this is an
> > >> issue.  We need to keep the copy functionality.
> > >> I'll think more and come back.  Hopefully more people weigh in to ...
> > >>
> > >> Cheers,
> > >>  Jesse
> > >>
> > >>
> > >>
> > >> @purplecabbage
> > >> risingj.com
> > >>
> > >> On Tue, Nov 29, 2016 at 9:06 AM, Karen Tran <ktop...@gmail.com>
> wrote:
> > >>
> > >>> I want to get some discussion on what the plugin.xml 
> > tag
> > >>> should be doing in Windows because I didn't know that it had been
> > changed
> > >>> for a while now.
> > >>>
> > >>> jira issue: https://issues.apache.org/jira/browse/CB-12163
> > >>>
> > >>> Current behavior: Doesn't copy resource file from src to target.
> > Instead,
> > >>> it will use a reference to the src location. This is the snippet from
> > >>> PluginHandler.js explaining this behavior, which was not added to the
> > >> docs.
> > >>> (https://issues.apache.org/jira/browse/CB-10326)
> > >>>
> > >>> // do not copy, but reference the file in the plugin folder. This
> > >>> allows to// have multiple source files map to the same target and
> > >>> select the appropriate// one based on the current build settings,
> e.g.
> > >>> architecture.// also, we don't check for existence. This allows to
> > >>> insert build variables// into the source file name, e.g.//
> > >>> 
> > >>>
> > >>>
> > >>> This is greatly different from the original intent of a the
> > >> 
> > >>> tag since it doesn't do a copy. I don't think that this new behavior
> > >> really
> > >>> should have replaced the copy functionality. It's a little
> unintuitive
> > to
> > >>> reference resources from outside the application. Not all resource
> > files
> > >>> are .dll, and there's no other reasonable tag to do a copy for files
> > that
> > >>> are not source files, lib files, or assets. (e.g, I'm using
> > resource-file
> > >>> tag with a .properties file, but because it does not get copied
> over, I
> > >>> can't reference my properties).
> > >>>
> > >>> These are the points I think we should come to a decision on
> > >>> 1. What should be the default behavior of  tag? Should
> > it
> > >>> simply be copy resources as it was originally intended to, or should
> it
> > >> be
> > >>> doing what it is now, which is making a reference to the resource
> > files.
> > >>> 2. Should  tag handle both functionalities, or should
> > one
> > >> be
> > >>> separated out into another tag?
> > >>>
> > >>
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> > For additional commands, e-mail: dev-h...@cordova.apache.org
> >
> >
>

[DISCUSSION] Windows tag, what should it be doing?

[Karen Tran]

I want to get some discussion on what the plugin.xml  tag
should be doing in Windows because I didn't know that it had been changed
for a while now.

jira issue: https://issues.apache.org/jira/browse/CB-12163

Current behavior: Doesn't copy resource file from src to target. Instead,
it will use a reference to the src location. This is the snippet from
PluginHandler.js explaining this behavior, which was not added to the docs.
(https://issues.apache.org/jira/browse/CB-10326)

// do not copy, but reference the file in the plugin folder. This
allows to// have multiple source files map to the same target and
select the appropriate// one based on the current build settings, e.g.
architecture.// also, we don't check for existence. This allows to
insert build variables// into the source file name, e.g.//



This is greatly different from the original intent of a the 
tag since it doesn't do a copy. I don't think that this new behavior really
should have replaced the copy functionality. It's a little unintuitive to
reference resources from outside the application. Not all resource files
are .dll, and there's no other reasonable tag to do a copy for files that
are not source files, lib files, or assets. (e.g, I'm using resource-file
tag with a .properties file, but because it does not get copied over, I
can't reference my properties).

These are the points I think we should come to a decision on
1. What should be the default behavior of  tag? Should it
simply be copy resources as it was originally intended to, or should it be
doing what it is now, which is making a reference to the resource files.
2. Should  tag handle both functionalities, or should one be
separated out into another tag?

Re: [VOTE] cordova-android@6.1.0 Release

[Karen Tran]

I vote +1:
* Created a new app using the android platform and ran on device
* Import to Android Studio and ran from Android Studio
* Upgraded an old version to the newest platform version

On Fri, Nov 4, 2016 at 6:23 PM, Shazron  wrote:

> I vote +1:
> * Ran coho audit-license-headers over the relevant repos
> * Ran coho check-license to ensure all dependencies and
> subdependencies have Apache-compatible licenses
> * Ensured tests passed (AppVeyor and Travis CI)
> * Created and emulated new app using the platform
>
> On Thu, Nov 3, 2016 at 12:57 PM, Joe Bowser  wrote:
>
> > Please review and vote on this 6.1.0 Android Release
> > by replying to this email (and keep discussion on the DISCUSS thread)
> >
> > Release issue: https://issues.apache.org/jira/browse/CB-12109
> >
> > The archive has been published to
> > dist/dev:https://dist.apache.org/repos/dist/dev/cordova/CB-12109
> >
> > The package was published from its corresponding git tag:
> >
> > cordova-android: 6.1.0 (e856613787)
> >
> > ote that you can test it out via:
> >
> > cordova platform add https://github.com/apache/cordova-android#6.1.0
> >
> > Upon a successful vote I will upload the archive to dist/, publish it
> > to npm, and post the blog post.
> > Voting guidelines:
> > https://github.com/apache/cordova-coho/blob/master/docs/
> release-voting.md
> > Voting will go on for a minimum of 48 hours.
> >
> > I vote +1:
> > * Ran coho audit-license-headers over the relevant repos
> > * Ran coho check-license to ensure all dependencies and
> > subdependencies have Apache-compatible licenses
> > * Ensured tests were correct and passed, and that appveyor was green
> > when repo was tagged.
> >
>

Re: [Android] Need a solution to config.xml and AndroidManifest.xml feature requests

[Karen Tran]

Can I get someone to review my PR?
https://github.com/apache/cordova-lib/pull/432

Thanks,
Karen Tran

On Thu, Apr 21, 2016 at 11:02 AM, Vladimir Kotikov (Akvelon) <
v-vlk...@microsoft.com> wrote:

> Exactly. Multiple tags is also possible with this syntax.
>
> -
> Best regards, Vladimir
>
> -Original Message-
> From: Karen Tran [mailto:ktop...@gmail.com]
> Sent: Thursday, April 21, 2016 5:20 PM
> To: dev@cordova.apache.org
> Subject: Re: [Android] Need a solution to config.xml and
> AndroidManifest.xml feature requests
>
> @Vladimir, in your suggestion, is this what you were going for? Being able
> to add multiple attributes to any direct children node of the parent?
>
> 
>  />
>  
>
>
>
> Regards,
> Karen Tran
>
> On Thu, Apr 21, 2016 at 3:58 AM, Vladimir Kotikov (Akvelon) <
> v-vlk...@microsoft.com> wrote:
>
> > Another proposal about syntax which allows to specify multiple
> > attributes at once and does not require parsing attributes from plain
> text:
> >
> > 
> >  
> >
> > Also I've took a quick look at the implementation and it looks good
> > apart from one minor issue - when we're grafting attributes we
> > probably do not need to create an element to graft attributes to if it
> > doesn't exist, otherwise after adding and then removing  the plugin
> > created xml element will remain in modified file.
> >
> > -
> > Best regards, Vladimir
> >
> > -Original Message-
> > From: Nikhil Khandelwal [mailto:nikhi...@microsoft.com]
> > Sent: Thursday, April 21, 2016 3:24 AM
> > To: dev@cordova.apache.org
> > Subject: RE: [Android] Need a solution to config.xml and
> > AndroidManifest.xml feature requests
> >
> > Oh great! I have not taken a close look at the implementation itself.
> > Perhaps you already had some of this in mind.
> >
> > As for the syntax for changing attributes, I would recommend something
> > like this:
> >
> >  > attributeName="android:name" attirbuteValue="MyApplication"/>
> >
> > Also, we should always prioritize config.xml edits over plugin.xml
> > (giving the end developer the full control). In case of conflicts,
> > between plugins & config.xml we should warn and mention which one we
> > picked (config.xml)
> >
> > Thanks,
> > Nikhil
> >
> > -Original Message-
> > From: Karen Tran [mailto:ktop...@gmail.com]
> > Sent: Wednesday, April 20, 2016 12:40 PM
> > To: dev@cordova.apache.org
> > Subject: Re: [Android] Need a solution to config.xml and
> > AndroidManifest.xml feature requests
> >
> > Hi,
> >
> > I made an attempt at the functionality of being able to add attributes
> > with the config-file tag. It's not completed yet, but I wanted to get
> > some review before I proceed.
> > With my changes, you can add an attribute through the config-file tag
> > in plugin.xml when the plugin is added, and when the plugin is
> > removed, the attribute will get removed.
> > https://github.com/ktop/cordova-lib/tree/cb-11023
> >
> > This is what the tag looks like:
> > * > parent="/manifest/application" attr="true">*
> > *android:name="MyApplication"*
> >
> > **
> >
> > Added *attr* attribute to let Config-File know that we want to add an
> > attribute. Default should be false and will expect an element rather
> > than an attribute.
> >
> > One issue I have is that it can only add 1 attribute per config-file tag.
> > This is the part that I still need to fix.
> >
> > Can someone review what I have so far?
> >
> > Thanks,
> > Karen
> >
> > On Tue, Apr 5, 2016 at 6:54 PM, Simon MacDonald
> > <simon.macdon...@gmail.com
> > >
> > wrote:
> >
> > > I would love to but I have a few other things to handle first. If
> > > someone else picks it up before I get to it then that's cool with me.
> > >
> > >
> > > Simon Mac Donald
> > > https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fhi.i
> > > m%
> > > 2fsimonmacdonald=01%7c01%7cnikhilkh%40microsoft.com%7c379bf4c2d
> > > ae
> > > 4454ee13008d369539a2b%7c72f988bf86f141af91ab2d7cd011db47%7c1=T
> > > vJ lf2LDyl%2bfSbRMDPjmLe%2fMBQf7PnAzRao5QANRrH4%3d
> > >
> > > On Tue, Apr 5, 2016 at 6:51 PM, Carlos Santana
> > > <csantan...@gmail.com>
> > > wrote:
> > >
> > > > Oh so it means 

Re: [Android] Need a solution to config.xml and AndroidManifest.xml feature requests

[Karen Tran]

@Vladimir, in your suggestion, is this what you were going for? Being able
to add multiple attributes to any direct children node of the parent?








Regards,
Karen Tran

On Thu, Apr 21, 2016 at 3:58 AM, Vladimir Kotikov (Akvelon) <
v-vlk...@microsoft.com> wrote:

> Another proposal about syntax which allows to specify multiple attributes
> at once and does not require parsing attributes from plain text:
>
> 
> 
> 
>
> Also I've took a quick look at the implementation and it looks good apart
> from one minor issue - when we're grafting attributes we probably do not
> need to create an element to graft attributes to if it doesn't exist,
> otherwise after adding and then removing  the plugin created xml element
> will remain in modified file.
>
> -
> Best regards, Vladimir
>
> -Original Message-
> From: Nikhil Khandelwal [mailto:nikhi...@microsoft.com]
> Sent: Thursday, April 21, 2016 3:24 AM
> To: dev@cordova.apache.org
> Subject: RE: [Android] Need a solution to config.xml and
> AndroidManifest.xml feature requests
>
> Oh great! I have not taken a close look at the implementation itself.
> Perhaps you already had some of this in mind.
>
> As for the syntax for changing attributes, I would recommend something
> like this:
>
>  attributeName="android:name" attirbuteValue="MyApplication"/>
>
> Also, we should always prioritize config.xml edits over plugin.xml (giving
> the end developer the full control). In case of conflicts, between plugins
> & config.xml we should warn and mention which one we picked (config.xml)
>
> Thanks,
> Nikhil
>
> -Original Message-
> From: Karen Tran [mailto:ktop...@gmail.com]
> Sent: Wednesday, April 20, 2016 12:40 PM
> To: dev@cordova.apache.org
> Subject: Re: [Android] Need a solution to config.xml and
> AndroidManifest.xml feature requests
>
> Hi,
>
> I made an attempt at the functionality of being able to add attributes
> with the config-file tag. It's not completed yet, but I wanted to get some
> review before I proceed.
> With my changes, you can add an attribute through the config-file tag in
> plugin.xml when the plugin is added, and when the plugin is removed, the
> attribute will get removed.
> https://github.com/ktop/cordova-lib/tree/cb-11023
>
> This is what the tag looks like:
> * parent="/manifest/application" attr="true">*
> *android:name="MyApplication"*
>
> **
>
> Added *attr* attribute to let Config-File know that we want to add an
> attribute. Default should be false and will expect an element rather than
> an attribute.
>
> One issue I have is that it can only add 1 attribute per config-file tag.
> This is the part that I still need to fix.
>
> Can someone review what I have so far?
>
> Thanks,
> Karen
>
> On Tue, Apr 5, 2016 at 6:54 PM, Simon MacDonald <simon.macdon...@gmail.com
> >
> wrote:
>
> > I would love to but I have a few other things to handle first. If
> > someone else picks it up before I get to it then that's cool with me.
> >
> >
> > Simon Mac Donald
> > https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fhi.im%
> > 2fsimonmacdonald=01%7c01%7cnikhilkh%40microsoft.com%7c379bf4c2dae
> > 4454ee13008d369539a2b%7c72f988bf86f141af91ab2d7cd011db47%7c1=TvJ
> > lf2LDyl%2bfSbRMDPjmLe%2fMBQf7PnAzRao5QANRrH4%3d
> >
> > On Tue, Apr 5, 2016 at 6:51 PM, Carlos Santana <csantan...@gmail.com>
> > wrote:
> >
> > > Oh so it means you don't want to work on the code :-p
> > >
> > >
> > > On Tue, Apr 5, 2016 at 6:50 PM Simon MacDonald <
> > simon.macdon...@gmail.com>
> > > wrote:
> > >
> > > > Thanks, I put a watch on that.
> > > >
> > > >
> > > > Simon Mac Donald
> > > > https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fhi
> > > > .im%2fsimonmacdonald=01%7c01%7cnikhilkh%40microsoft.com%7c379
> > > > bf4c2dae4454ee13008d369539a2b%7c72f988bf86f141af91ab2d7cd011db47%7
> > > > c1=TvJlf2LDyl%2bfSbRMDPjmLe%2fMBQf7PnAzRao5QANRrH4%3d
> > > >
> > > > On Tue, Apr 5, 2016 at 6:48 PM, Carlos Santana
> > > > <csantan...@gmail.com>
> > > > wrote:
> > > >
> > > > > Simon, I was not able to find a JIRA, I created a new JIRA [1]
> > > > > to
> > > enhance
> > > > > plugin.xml to allow  to add attributes
> > > > >
> > > > > [1]:
> > > > > https://na01.safelinks.protection.outlook.com/?url=ht

Re: [Android] Need a solution to config.xml and AndroidManifest.xml feature requests

[Karen Tran]

Hi,

I made an attempt at the functionality of being able to add attributes with
the config-file tag. It's not completed yet, but I wanted to get some
review before I proceed.
With my changes, you can add an attribute through the config-file tag in
plugin.xml when the plugin is added, and when the plugin is removed, the
attribute will get removed.
https://github.com/ktop/cordova-lib/tree/cb-11023

This is what the tag looks like:
**
*android:name="MyApplication"*

**

Added *attr* attribute to let Config-File know that we want to add an
attribute. Default should be false and will expect an element rather than
an attribute.

One issue I have is that it can only add 1 attribute per config-file tag.
This is the part that I still need to fix.

Can someone review what I have so far?

Thanks,
Karen

On Tue, Apr 5, 2016 at 6:54 PM, Simon MacDonald 
wrote:

> I would love to but I have a few other things to handle first. If someone
> else picks it up before I get to it then that's cool with me.
>
>
> Simon Mac Donald
> http://hi.im/simonmacdonald
>
> On Tue, Apr 5, 2016 at 6:51 PM, Carlos Santana 
> wrote:
>
> > Oh so it means you don't want to work on the code :-p
> >
> >
> > On Tue, Apr 5, 2016 at 6:50 PM Simon MacDonald <
> simon.macdon...@gmail.com>
> > wrote:
> >
> > > Thanks, I put a watch on that.
> > >
> > >
> > > Simon Mac Donald
> > > http://hi.im/simonmacdonald
> > >
> > > On Tue, Apr 5, 2016 at 6:48 PM, Carlos Santana 
> > > wrote:
> > >
> > > > Simon, I was not able to find a JIRA, I created a new JIRA [1] to
> > enhance
> > > > plugin.xml to allow  to add attributes
> > > >
> > > > [1]: https://issues.apache.org/jira/browse/CB-11023
> > > >
> > > >
> > > > On Wed, Mar 23, 2016 at 11:30 AM Simon MacDonald <
> > > > simon.macdon...@gmail.com>
> > > > wrote:
> > > >
> > > > > Seems like editing attributes in a config-file is a wanted
> > enhancement.
> > > > Do
> > > > > we have a JIRA for it?
> > > > >
> > > > >
> > > > > Simon Mac Donald
> > > > > http://hi.im/simonmacdonald
> > > > >
> > > > > On Tue, Mar 22, 2016 at 5:09 PM, Carlos Santana <
> > csantan...@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > I agree to enable config.xml to be able to set or override using
> > > > > > config-file (i.e. any xml file including strings.xml)
> > > > > > I also think that adding support in config.xml and plugin.xml to
> > edit
> > > > > > attributes is very helpful, this is exactly what we are doing for
> > one
> > > > of
> > > > > > our plugin to add the attribute android:name for 
> and
> > it
> > > > > was a
> > > > > > pain, and I think we still have problems doing it from
> > > > > > before_plugin_install hook, it would be easier from plugin.xml
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Tue, Mar 22, 2016 at 10:55 AM julio cesar sanchez <
> > > > > > jcesarmob...@gmail.com>
> > > > > > wrote:
> > > > > >
> > > > > > > Yes, Simon, that's my opinion, and we should show the
> conficting
> > > > values
> > > > > > and
> > > > > > > the id of the plugin with the conficting values so the user
> knows
> > > he
> > > > > has
> > > > > > to
> > > > > > > change the values on the config.xml or remove the plugin.
> > > > > > >
> > > > > > > But we still will have problems if the plugin uses a hook to
> > write
> > > > > values
> > > > > > > instead of using the config-file tag
> > > > > > >
> > > > > > > 2016-03-22 15:11 GMT+01:00 Alexis Kofman <
> > alexis.kof...@gmail.com
> > > >:
> > > > > > >
> > > > > > > > Maybe the configured values of the plugins are sometimes just
> > > > default
> > > > > > > > values that the user can override through the config.xml
> file.
> > > > > > > > What about adding a flag indicating whether the value is
> > > > overridable
> > > > > ?
> > > > > > > My 2
> > > > > > > > cents ...
> > > > > > > >
> > > > > > > > On Tue, Mar 22, 2016 at 3:02 PM, Simon MacDonald <
> > > > > > > > simon.macdon...@gmail.com>
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > > So for Android's case you are thinking the order of
> > precedence
> > > > > should
> > > > > > > be:
> > > > > > > > >
> > > > > > > > > config.xml
> > > > > > > > > plugin.xml
> > > > > > > > > AndroidManifest.xml // created by the "cordova" cli
> > > > > > > > >
> > > > > > > > > Then if config.xml overrides something that one of the
> > plugins
> > > > > > depends
> > > > > > > on
> > > > > > > > > then the app won't build. I can actually get behind that
> > > proposal
> > > > > if
> > > > > > > I'm
> > > > > > > > > understanding you correctly.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > Simon Mac Donald
> > > > > > > > > http://hi.im/simonmacdonald
> > > > > > > > >
> > > > > > > > > On Tue, Mar 22, 2016 at 9:51 AM, julio cesar sanchez <
> > > > > > > > > jcesarmob...@gmail.com
> > > > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > > I think, if there is a conflict between config.xml and
> > > > 

Re: [Android] 5.0.x release branch?

[Karen Tran]

Hi Joe,

I tested your geolocation plugin changes with mobilespec and the app
crashes when you click "Deny" permission and when you click "Accept"
permission for the first time. When you go back to the app after accepting,
you can get location data.

I agree with having a 5.0.x branch soon since I know some people are
already asking about using API 23 and needing to test it asap.


On Mon, Sep 21, 2015 at 9:32 PM, Joe Bowser  wrote:

> On Mon, Sep 21, 2015 at 5:43 PM Nikhil Khandelwal 
> wrote:
>
> > Can you explain why latest plugins will not be compatible with older
> > versions of Cordova?
>
>
> They won't be compatible because Cordova-Android compiles against API 22,
> and these plugins will require API 23 so that they can detect permissions
> and support Marshmellow.
>
>
> > Can this be avoided by any means?
>
>
> Only with a lot of Java reflection, and I'd rather not subject plugin
> developers to that, or try to hide it under the hood in some awful utility
> class that everyone will want to see die.  I'm very much a fan of if
> statements because they work, and they're easy to read and debug, unlike
> when bad things happen to things you reflect into.  Plugins that require
> API 23 will only work with Cordova-Android 5.0 and up.  This only impacts
> five of our core plugins, but any plugin that requires permissions from the
> Android Manifest will have to be updated.  If we can avoid using advanced
> language tricks to make the APKs compatible, we should do that.
>
> When you mean they would not be compatible - will it result in a build or
> > runtime failure?
> >
> >
> This will be a build failure, since API 22 does not have these permissions,
> nor does it have the code required for API 23.
>
>
> > For marshmallow, what is the guidance that we need to issue to the larger
> > Cordova plugin ecosystem? Joe you are ahead of the curve here compared to
> > most other plugin developers - a blot post explaining what are known
> > gotchas would be great. I really hope we can use our Cordova blog to
> > communicate these changes actively to the plugin ecosystem. This mailing
> > list only gets 400+ subscribers.
> >
> >
> There will be a blog post once 5.0 is released.  We're not forcing people
> to upgrade to 5.0, and we will be supporting the 4.x branch for six
> months.  This does mean we're stuck supporting 3.x, 4.x and 5.x for a brief
> window, but I have no control over when Marshmallow is released, only
> whether we want to support it or not.  I think we do, but I could be wrong.
>
> At least this should be easier than the jump from 3.x to 4.x for most
> people, but the alternative is that your plugin just doesn't work at all on
> Marshmallow.  We need to at least give plugin developers this option, since
> it'll roll out on all the Nexus devices in the next two weeks, and we'll
> hear more about it.
>
>
> > Can you re-base your cordova-android over the current master? It's hard
> to
> > see a diff in the current form:
> >
> https://github.com/apache/cordova-android/compare/master...infil00p:smores
> >
> >
> I had to do a merge commit to get this to happen (boo), but it should be
> mostly cleaned up now.  It seems some style cleanup creeped into the most
> recent changes, but this should be a bit more readable.
>
>
> > -Nikhil
> >
> > -Original Message-
> > From: Joe Bowser [mailto:bows...@gmail.com]
> > Sent: Monday, September 21, 2015 2:14 PM
> > To: dev 
> > Subject: [Android] 5.0.x release branch?
> >
> > Hey
> >
> > In the next two weeks, Marshmallow will most likely getting released with
> > the brand new Nexus 6P being released from Huawei.  Given that most of
> the
> > Nexus devices will be getting this release, we should probably release
> the
> > 5.0.x branch of Android soon, and get the new plugins updated.
> >
> > It should be noted that the latest plugins will not be compatible with
> > older versions of Cordova, which is a big deal.  This is due to the use
> of
> > various compatibility checks to make sure they support Marshmallow and
> > older versions of Android.
> >
> > So, if everyone can look over the smores branches of my GitHub before I
> > create the 5.0.x branch and pull the changes into it, that would be
> awesome.
> >
> >
> >
> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithub.com%2finfil00p%2fcordova-android%2ftree%2fsmores=01%7c01%7cnikhilkh%40microsoft.com%7c1785194b1f82494fc2d908d2c2c99f36%7c72f988bf86f141af91ab2d7cd011db47%7c1=%2fPKmL8KTsz5dnC3A75yMatXLQUnfK0Nv07%2bve4PVcCE%3d
> >
> >
> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithub.com%2finfil00p%2fcordova-plugin-geolocation%2ftree%2fsmores=01%7c01%7cnikhilkh%40microsoft.com%7c1785194b1f82494fc2d908d2c2c99f36%7c72f988bf86f141af91ab2d7cd011db47%7c1=o6cLXM4f3kpUGCTlIv65ft8lKv6pc5qbeY%2bdUxiP4bc%3d
> >
> >
> 

Re: Marshmallow Update and Cordova-Android 5.0

[Karen Tran]

I tested your camera plugin through mobilespec and the permissions are
working.

On Thu, Sep 3, 2015 at 12:10 PM, Joe Bowser <bows...@gmail.com> wrote:

> On Thu, Sep 3, 2015 at 8:07 AM Karen Tran <ktop...@gmail.com> wrote:
>
> > Hi Joe,
> >
> > I tested your patch and it works for the most part using mobilespec's
> > manual test for contacts. I do see the prompt for permissions contacts,
> but
> > not explicitly to read or write contacts like you mentioned.
> >
> > I don't either, even though I'm explicitly promoting for the permission.
> Also, I found that if you prompt for READ permissions, you get both READ
> and WRITE.
>
>
> > One thing that doesn't work is if you click "Deny" permission, the app
> > crashes. I don't think we'd want that to happen, so we'll have to handle
> > that case.
> >
>
> It should work now.  I forgot to return out of the method once the
> permission is denied.
>
>
> >
> > And as for the contact autotests, they're a bit finicky now with a couple
> > of failures.
> >
>
> Contacts has always been finicky, and needs a full re-write.  I wasn't
> intending to fully fix this plugin (because of time), just get the
> permissions working because it's the low hanging fruit.  Any change to the
> flow of the tests will break the tests because of concurrency issues with
> the Android Contacts API.
>
> I also have the Camera using the plugin, since we rely on external storage
> for determining whether we're going to produce duplicates.
>
> https://github.com/infil00p/cordova-plugin-camera/tree/smores
>
>
>
> > On Tue, Sep 1, 2015 at 9:39 AM, Carlos Santana <csantan...@gmail.com>
> > wrote:
> >
> > > Joe I understand the feeling. One part of me saying that we should name
> > the
> > > version 4.2 since there are no API changes.
> > > But my other part says that if developer's ignore because is 4.x stuff
> > will
> > > break in new major release of Android M (23)
> > >
> > > I would say that also agree that best option is to name is
> > > cordova-android@5
> > > , then is clear to developers that they can use targetsdk=23 and also
> new
> > > major versions for the affected plugins that need updates to support
> > > targetsdk=23
> > >
> > > But as you can see this is less important that getting the plugins to
> > work
> > > correctly with permissions :-)
> > >
> > >
> > >
> > > On Tue, Sep 1, 2015 at 12:03 AM Joe Bowser <bows...@gmail.com> wrote:
> > >
> > > > BTW: I got Contacts somewhat working with Marshmellow.  It's still
> got
> > > the
> > > > same crappy concurrency bugs that it always has, and I am not sure
> how
> > to
> > > > resolve those without re-writing the damn thing, but the purpose of
> > this
> > > is
> > > > to figure out how to get permissions to work, and I have something
> that
> > > > works.
> > > >
> > > > https://github.com/infil00p/cordova-plugin-contacts/tree/smores
> > > >
> > > > This works with the latest smores tree of Cordova Android, and I
> tested
> > > it
> > > > on Lollipop and Marshmellow.  I'm going to move on to some of the
> other
> > > > plugins to get them ready for Marshmellow, but it'd be good to have
> > > people
> > > > look these over.
> > > >
> > > > I did find a nasty security bug with this, though.  If you request
> one
> > > > permission out of the permission group, you get all the permissions.
> > So,
> > > > anything that can read contacts can magically write contacts even if
> > you
> > > > don't request that permission explicitly.  I think this is a serious
> > bug,
> > > > and I'm going to dig tomorrow to see if someone already reported it.
> > > >
> > > > On Mon, Aug 31, 2015 at 11:35 AM Joe Bowser <bows...@gmail.com>
> wrote:
> > > >
> > > > > Hey
> > > > >
> > > > > So, I created a new topic branch of my github with the new changes
> as
> > > > > suggested earlier.
> > > > >
> > > > > https://github.com/infil00p/cordova-android/tree/smores
> > > > >
> > > > > The thing we have to make sure works is if the user turns off the
> > > > > permissions on Marshmellow.  Right now if the permissions are off,
> > > > > everything crashes and dies, so we're going to issue a 5.0 because
> > > > plugins
> > > > > will have to have this code to work on the latest version of
> Android.
> > > > It's
> > > > > not a API change, since we're adding it, but I feel that it's
> > important
> > > > > enough that we should bump the major version anyway.
> > > > >
> > > > > Can we PLEASE not have any other features creep into 5.0?  If we
> need
> > > > > additional features, we can do a 6.0.  I'm not against bumping
> major
> > > > > versions as long as we get into a trend of not breaking shit like
> we
> > > did
> > > > in
> > > > > the bump from 3.7 to 4.0.
> > > > >
> > > > > Also, we're going to deprecate 3.7, is there any major third-party
> > > > plugins
> > > > > that still don't work with 4.0.x that we should be aware of?  Do we
> > > have
> > > > > people to cover the docs on that.
> > > > >
> > > > > Thoughts?
> > > > >
> > > > > Joe
> > > > >
> > > > >
> > > > >
> > > >
> > >
> >
>

Re: Marshmallow Update and Cordova-Android 5.0

[Karen Tran]

Hi Joe,

I tested your patch and it works for the most part using mobilespec's
manual test for contacts. I do see the prompt for permissions contacts, but
not explicitly to read or write contacts like you mentioned.

One thing that doesn't work is if you click "Deny" permission, the app
crashes. I don't think we'd want that to happen, so we'll have to handle
that case.

And as for the contact autotests, they're a bit finicky now with a couple
of failures.

On Tue, Sep 1, 2015 at 9:39 AM, Carlos Santana  wrote:

> Joe I understand the feeling. One part of me saying that we should name the
> version 4.2 since there are no API changes.
> But my other part says that if developer's ignore because is 4.x stuff will
> break in new major release of Android M (23)
>
> I would say that also agree that best option is to name is
> cordova-android@5
> , then is clear to developers that they can use targetsdk=23 and also new
> major versions for the affected plugins that need updates to support
> targetsdk=23
>
> But as you can see this is less important that getting the plugins to work
> correctly with permissions :-)
>
>
>
> On Tue, Sep 1, 2015 at 12:03 AM Joe Bowser  wrote:
>
> > BTW: I got Contacts somewhat working with Marshmellow.  It's still got
> the
> > same crappy concurrency bugs that it always has, and I am not sure how to
> > resolve those without re-writing the damn thing, but the purpose of this
> is
> > to figure out how to get permissions to work, and I have something that
> > works.
> >
> > https://github.com/infil00p/cordova-plugin-contacts/tree/smores
> >
> > This works with the latest smores tree of Cordova Android, and I tested
> it
> > on Lollipop and Marshmellow.  I'm going to move on to some of the other
> > plugins to get them ready for Marshmellow, but it'd be good to have
> people
> > look these over.
> >
> > I did find a nasty security bug with this, though.  If you request one
> > permission out of the permission group, you get all the permissions.  So,
> > anything that can read contacts can magically write contacts even if you
> > don't request that permission explicitly.  I think this is a serious bug,
> > and I'm going to dig tomorrow to see if someone already reported it.
> >
> > On Mon, Aug 31, 2015 at 11:35 AM Joe Bowser  wrote:
> >
> > > Hey
> > >
> > > So, I created a new topic branch of my github with the new changes as
> > > suggested earlier.
> > >
> > > https://github.com/infil00p/cordova-android/tree/smores
> > >
> > > The thing we have to make sure works is if the user turns off the
> > > permissions on Marshmellow.  Right now if the permissions are off,
> > > everything crashes and dies, so we're going to issue a 5.0 because
> > plugins
> > > will have to have this code to work on the latest version of Android.
> > It's
> > > not a API change, since we're adding it, but I feel that it's important
> > > enough that we should bump the major version anyway.
> > >
> > > Can we PLEASE not have any other features creep into 5.0?  If we need
> > > additional features, we can do a 6.0.  I'm not against bumping major
> > > versions as long as we get into a trend of not breaking shit like we
> did
> > in
> > > the bump from 3.7 to 4.0.
> > >
> > > Also, we're going to deprecate 3.7, is there any major third-party
> > plugins
> > > that still don't work with 4.0.x that we should be aware of?  Do we
> have
> > > people to cover the docs on that.
> > >
> > > Thoughts?
> > >
> > > Joe
> > >
> > >
> > >
> >
>

Re: Android Marshmallow Permissions

[Karen Tran]

I realized I goofed and that accessing the camera wasn't actually a
permission itself. It was permission for the camera to access your
location. So everything should be working fine for older sdk + M preview.
The issue about not returning to the app that calls the camera after
accepting this permission is still a bug.

On Fri, Aug 21, 2015 at 1:14 AM, Joe Bowser bows...@gmail.com wrote:

 On Thu, Aug 20, 2015 at 9:28 PM Karen Tran ktop...@gmail.com wrote:

  Hi all,
 
  I've been doing some testing with Android M Preview 3 and with Android
 API
  23 to investigate the behavior I'm seeing with permissions.
  I tested older sdk levels with M Preview 3, API 23 with Preview 3, and
 API
  23 with Lollipop.
  * If anyone has different results, let me know.
 
  On master, the target sdk level is currently set to 22.
  Running mobilespec at this target level on the 3rd Preview, all the
  automatic plugin tests passes.
  For manual tests, there are also no regressions, however, when testing
 the
  camera, I get prompted for permission.
 
 
 This seems odd, since we're using intents to do camera, so it may be camera
 asking for the camera permission? It's listed in the Android Best Practices
 now, which is hilarious, since we get so much hostility for using intents
 instead of owning our own camera.


  This is a bit odd because older sdk running on the Preview should use the
  old permission model, which is granting permission at install time, not
  runtime as stated in the Android documentation.


 Unless Camera is using the new permission model, because it's the new app.
 That said, the default Android Camera should already have permission.  I
 think that this will literally be a one time thing.


 

 Another odd behavior is if I accept this permission for mobilespec, I never
  have to accept again, even if another app is accessing the camera.


 That sounds like the intent for camera asking for the permission, not
 MobileSpec.


  I tested
  this with another cordova app I made that calls the camera plugin.
  The last odd behavior I noticed is when you accept for camera, the camera
  app itself opens, so when you take a picture, you don't return to
  mobilespec. You just stay in the camera app. This only happens right
 after
  accepting. When you go back to mobilespec manually and use the camera
  again, the expected behavior of the camera resumes and your picture shows
  up in the yellow box of mobilespec.
 
 
 That is interesting, there's probably a bug with using intents this way,
 and a native Android Test app should be written to demonstrate this
 behaviour.  This is very low priority, since most people will use the
 camera before using any other application.


  The above behaviors also happen with older sdk levels.
 
 
  Now manually setting the target sdk level to 23, all permissions are off
 by
  default, I don't get prompted for any permissions either when trying to
 run
  manual plugin tests. Of course having no permissions on, certain plugin
  tests will fail. Turning them all on manually, everything passes.
  Documentation of the new permission model says that we'll need to add
 some
  code to check for permissions and request them.
 
 
 That's currently as expected.  We are currently working on code to ask for
 permissions, and we should be re-writing the plugins to expect the code to


 
  *On your apps that target the M Preview release or higher, make sure to
  check for and request permissions at runtime. To determine if your app
 has
  been granted a permission, call the newcheckSelfPermission() method. To
  request a permission, call the new requestPermissions() method. Even if
  your app is not targeting the M Preview release, you should test your app
  under the new permissions model.*
 
  The cordova permissions we'll need to handle are :
  - contacts
  - location
  - microphone
  - phone
  - storage
 
 
 Actually, plugin authors need to be able to handle all the permissions and
 ask for them.  I have no idea what a third party plugin is going to need to
 access stuff, but I do know that it's bigger than the list here.  Some may
 want some access to the phone itself, and to make calls. Those are the
 permissions our plugins need to ask for.


 
  Lastly testing Lollipop and older with API 23 looks fine.
 
 
  *TL;DR *
  Using M Preview with API 22 and older should be using the old permission
  model. All tests are passing except some strange behavior with the manual
  camera test which prompts for permission at runtime.
  Using M Preview with API 23 should use the new permission model where
 apps
  should request permission at runtime. Our cordova plugins will need to be
  updated to handle this.
  Using Lollipop and older with API 23 should use the old permission
 model. I
  didn't see any problems here.
 
 
 If you turn a permission off manually, there's problems and we should have
 code that addresses those problems.  Since we target the lowest API, we
 will by default always have our

Android Marshmallow Permissions

[Karen Tran]

Hi all,

I've been doing some testing with Android M Preview 3 and with Android API
23 to investigate the behavior I'm seeing with permissions.
I tested older sdk levels with M Preview 3, API 23 with Preview 3, and API
23 with Lollipop.
* If anyone has different results, let me know.

On master, the target sdk level is currently set to 22.
Running mobilespec at this target level on the 3rd Preview, all the
automatic plugin tests passes.
For manual tests, there are also no regressions, however, when testing the
camera, I get prompted for permission.

This is a bit odd because older sdk running on the Preview should use the
old permission model, which is granting permission at install time, not
runtime as stated in the Android documentation.
Another odd behavior is if I accept this permission for mobilespec, I never
have to accept again, even if another app is accessing the camera. I tested
this with another cordova app I made that calls the camera plugin.
The last odd behavior I noticed is when you accept for camera, the camera
app itself opens, so when you take a picture, you don't return to
mobilespec. You just stay in the camera app. This only happens right after
accepting. When you go back to mobilespec manually and use the camera
again, the expected behavior of the camera resumes and your picture shows
up in the yellow box of mobilespec.

The above behaviors also happen with older sdk levels.


Now manually setting the target sdk level to 23, all permissions are off by
default, I don't get prompted for any permissions either when trying to run
manual plugin tests. Of course having no permissions on, certain plugin
tests will fail. Turning them all on manually, everything passes.
Documentation of the new permission model says that we'll need to add some
code to check for permissions and request them.


*On your apps that target the M Preview release or higher, make sure to
check for and request permissions at runtime. To determine if your app has
been granted a permission, call the newcheckSelfPermission() method. To
request a permission, call the new requestPermissions() method. Even if
your app is not targeting the M Preview release, you should test your app
under the new permissions model.*

The cordova permissions we'll need to handle are :
- contacts
- location
- microphone
- phone
- storage


Lastly testing Lollipop and older with API 23 looks fine.


*TL;DR *
Using M Preview with API 22 and older should be using the old permission
model. All tests are passing except some strange behavior with the manual
camera test which prompts for permission at runtime.
Using M Preview with API 23 should use the new permission model where apps
should request permission at runtime. Our cordova plugins will need to be
updated to handle this.
Using Lollipop and older with API 23 should use the old permission model. I
didn't see any problems here.


Regards,
Karen

Re: [Android] Working with M - An update

[Karen Tran]

I just tried the manual geolocation tests on mobilespec with the 3rd
preview and I am able to get location data now.
Thanks for the help Andrew!

On Mon, Aug 17, 2015 at 11:29 AM, Carlos Santana csantan...@gmail.com
wrote:

 Hey Andrew any update on this, Do you have a link we can track progress? Or
 do you know if latest preview dropped contains this fix?

 By the way when is Android M suppose to be General Available?


 On Fri, Jul 24, 2015 at 1:56 PM Andrew Grieve agri...@chromium.org
 wrote:

  Was out last week, but did manage to escalate the geolocation bug. Will
  hopefully be fixed for official M release :)
 
  On Thu, Jul 16, 2015 at 1:31 PM, Joe Bowser bows...@gmail.com wrote:
 
   Sent you the test app off-list.
  
   On Wed, Jul 15, 2015 at 11:12 AM Andrew Grieve agri...@chromium.org
   wrote:
  
Thanks for looking into this Joe! The runtime permissions is quite a
  big
change!
   
M is still in preview, so if you find any webview bugs, please feel
  free
   to
send me a repro app and I'll do my best to get it fixed.
   
In terms of Cordova API changes, here's some thoughts on your branch:
- Plugins may want to request different perms at different times, so
  I'd
remove new functions from CordovaPlugin except
  onRequestPermissionResult
- Might be better to copy how CordovaInterfaceImpl does
startActivityForResult/onActivityResponse rather than have
  PluginManager
   do
it.
   
   
On Tue, Jul 14, 2015 at 6:07 PM, Joe Bowser bows...@gmail.com
 wrote:
   
 So, since Cordova-Android wasn't completely killed off by Google at
  the
 last Google IO like I thought it would be, we're going to have to
  make
sure
 it's compatible with Android M (Marshmellow? Marzipan?).  The good
  news
is
 that this only affects the following plugins:

 MediaRecorder
 Contacts
 File
 FileTransfer
 Geolocation

 Now, for the really bad news.  We might have to write a Geolocation
plugin
 for Android again, because Google's Android WebView doesn't play
 nice
with
 Android's new permission system, and even when you do grant the
application
 containing the process permission to use geolocation, you still
 get a
 location error.  I still have to test this further, but it also may
  be
 possible that file URIs no longer have the ability to get the
   geolocation
 either, which would be weird, since this would be a Chrome thing
 and
   not
an
 Android thing.

 Given our poor track record of maintaining plugins in general, and
  the
 weird errors with Geolocation, I'm not really wanting to bring back
  the
 code, so I'm hoping that this gets resolved in M3 with the next dev
version
 of M.

 But so far, I have the changes that I made to Cordova on a private
   branch
 on Github that people can see here:

 https://github.com/infil00p/cordova-android/tree/m-compat

 Let me know if you have any questions.  I'm not sure whether this
  makes
 perfect sense yet, but I think these API changes indicate that we
   should
 probably bump the version to 5.0 once M comes out.

 Thoughts? Questions?

   
  
 

Re: [Proposal - New Feature] Add tag to config.xml to handle images

[Karen Tran]

Yes, I agree, and the notification icon is a good example. There is nothing
in config.xml that currently does just a copy over, which is why I'm
proposing to add this functionality in. I am actually just using a hook
script to copy the images over right now, but I figure it might be
beneficial to add this feature in since it's very common to have other
sorts of icon images that aren't the main application icon.

Your suggestion of using a name attribute would work, and might be better
than have a new tag since it would be redundant to have two separate icon
tags doing almost the same thing.

What did you mean by one-off asset problems on other platforms?

On Sun, May 3, 2015 at 7:36 PM, Darryl Pogue dvpdin...@gmail.com wrote:

 One example that comes to mind is notification icons for Android. It
 used to be fine to reuse the app icon, but as of Lollipop notification
 icons are only transparent and white. If your app icon is square, your
 notification icon will be a white square unless you provide a
 different one.

 Currently there's no way to use config.xml to copy a notification icon
 (or any other non-app icon). If you're treating your platforms as
 build artifacts, this means you have to write hooks to copy stuff in
 manually.

 Something like
 icon src=res/android/notification.png density=mdpi
 name=ic_notification
 would be ideal for that use case.


 I do think this turns into a slippery slope pretty quickly though,
 because a case can probably be made for all sorts of one-off asset
 problems on other platforms and we probably don't want all of those
 things ending up in config.xml.

 On 3 May 2015 at 16:30, Karen Tran ktop...@gmail.com wrote:
  Buttons were just an example. The image could really be of anything the
  user wants in the application.
 
  What's in cordova now in config.xml is:
 
  icon src=res/android/button.png platform=android density=mdpi /
 
  The line above will copy button.png into the drawable-mdpi directory and
  rename it to icon.png, thus replacing the icon.png that is already there.
  Of course as a result, my application will be using button.png as the
 main
  icon.
  I don't want this.
 
  I want a new tag, which is similar to icon, but all it does is copy the
  image over. No renaming to icon.png. Just plain old copy.
 
  *image* src=res/android/button.png platform=android density=mdpi
 /
 
  In cordova-lib/cordova-lib/src/cordova/metadata/android-parser.js is
 where
  config.xml gets parsed to handle the icon tag. I believe I can just reuse
  the code there for this new tag that I want to create, but I just wanted
 to
  see if anyone had any objections.
 
 
  On Sat, May 2, 2015 at 5:12 PM, julio cesar sanchez 
 jcesarmob...@gmail.com
  wrote:
 
  But you want it for native buttons?
  If not, you can just put the images on the www folder
 
  El viernes, 1 de mayo de 2015, Karen Tran ktop...@gmail.com escribió:
 
   I am looking for a way to be able to specify an image in the
 config.xml
  and
   have it be placed in the drawable directory. Under my circumstances, I
  have
   to assume that when the user creates a cordova project, he/she only
 knows
   how to modify the config.xml, so that's why I'm pushing for a way to
 do
  it
   this way.
  
   I do have a hackish way of doing it by using the preferences tag and
   getting the path to the image, and then having a script copy it over,
  but I
   know the better way to do it would be to just make a tag to take care
 of
   images that are not going to be the main icon or splash image and have
   cordova-cli handle it for me when I call cordova prepare.
  
   This isn't really for a plugin, though maybe an app template, but I
 just
   wanted to add this functionality to be able to specify non-icon and
   non-splash images through the config.xml.
  
   I've found where in cordova-lib that the parsing happens for the icon
 and
   splash tags, so I was proposing to add a new tag for general images.
  The
   images could be anything that a user might want in his or her app. An
   example would be a customized button. The user can specify the path to
  the
   image file, and then the image will be dropped into the drawable
  directory.
  
   On Fri, May 1, 2015 at 12:27 PM, Jesse purplecabb...@gmail.com
   javascript:; wrote:
  
What is the use for the images? Is this for a plugin, or an app
  template?
I can think of a couple ways to do this, but none would affect
configure.xml.but
I suggest you look at how the splash screen plugin does this for
  android.
   
   
   
 On May 1, 2015, at 8:39 AM, Karen Tran ktop...@gmail.com
   javascript:; wrote:

 Hi dev-list,

 I wanted to get your input on a feature I want to add to the
   config.xml.

 Currently there are only the icon tag and splash tag that allows
 the
   user
 to specify the icon and splash image in the config.xml
 respectively.

 I want to be able to specify multiple images that will be used in
 my
   app

Re: [Proposal - New Feature] Add tag to config.xml to handle images

[Karen Tran]

Buttons were just an example. The image could really be of anything the
user wants in the application.

What's in cordova now in config.xml is:

icon src=res/android/button.png platform=android density=mdpi /

The line above will copy button.png into the drawable-mdpi directory and
rename it to icon.png, thus replacing the icon.png that is already there.
Of course as a result, my application will be using button.png as the main
icon.
I don't want this.

I want a new tag, which is similar to icon, but all it does is copy the
image over. No renaming to icon.png. Just plain old copy.

*image* src=res/android/button.png platform=android density=mdpi /

In cordova-lib/cordova-lib/src/cordova/metadata/android-parser.js is where
config.xml gets parsed to handle the icon tag. I believe I can just reuse
the code there for this new tag that I want to create, but I just wanted to
see if anyone had any objections.


On Sat, May 2, 2015 at 5:12 PM, julio cesar sanchez jcesarmob...@gmail.com
wrote:

 But you want it for native buttons?
 If not, you can just put the images on the www folder

 El viernes, 1 de mayo de 2015, Karen Tran ktop...@gmail.com escribió:

  I am looking for a way to be able to specify an image in the config.xml
 and
  have it be placed in the drawable directory. Under my circumstances, I
 have
  to assume that when the user creates a cordova project, he/she only knows
  how to modify the config.xml, so that's why I'm pushing for a way to do
 it
  this way.
 
  I do have a hackish way of doing it by using the preferences tag and
  getting the path to the image, and then having a script copy it over,
 but I
  know the better way to do it would be to just make a tag to take care of
  images that are not going to be the main icon or splash image and have
  cordova-cli handle it for me when I call cordova prepare.
 
  This isn't really for a plugin, though maybe an app template, but I just
  wanted to add this functionality to be able to specify non-icon and
  non-splash images through the config.xml.
 
  I've found where in cordova-lib that the parsing happens for the icon and
  splash tags, so I was proposing to add a new tag for general images.
 The
  images could be anything that a user might want in his or her app. An
  example would be a customized button. The user can specify the path to
 the
  image file, and then the image will be dropped into the drawable
 directory.
 
  On Fri, May 1, 2015 at 12:27 PM, Jesse purplecabb...@gmail.com
  javascript:; wrote:
 
   What is the use for the images? Is this for a plugin, or an app
 template?
   I can think of a couple ways to do this, but none would affect
   configure.xml.but
   I suggest you look at how the splash screen plugin does this for
 android.
  
  
  
On May 1, 2015, at 8:39 AM, Karen Tran ktop...@gmail.com
  javascript:; wrote:
   
Hi dev-list,
   
I wanted to get your input on a feature I want to add to the
  config.xml.
   
Currently there are only the icon tag and splash tag that allows the
  user
to specify the icon and splash image in the config.xml respectively.
   
I want to be able to specify multiple images that will be used in my
  app
such as customized buttons. The problem is that the icon tag will
  rename
the image specified to icon.png, so ultimately the user would only be
   able
to change the main icon. And the splash tag of course handles the
  splash
image, so I don't want that.
   
I propose making a new tag that handles general images. It'll be
  similar
   to
the icon tag, except it won't rename the image. It will copy the
 image
   from
the src, and drop it into the correct drawable-density directory (I
 am
working in android).
   
I know I can just drop the images myself into the drawable folders,
  but I
have to assume that my users won't know the android project structure
  and
will only modify the config.xml.
   
Any thoughts, comments, or critiques would be appreciated.
   
   
Regards,
Karen Tran
  
   -
   To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
  javascript:;
   For additional commands, e-mail: dev-h...@cordova.apache.org
  javascript:;
  
  
 

Re: [Proposal - New Feature] Add tag to config.xml to handle images

[Karen Tran]

I am looking for a way to be able to specify an image in the config.xml and
have it be placed in the drawable directory. Under my circumstances, I have
to assume that when the user creates a cordova project, he/she only knows
how to modify the config.xml, so that's why I'm pushing for a way to do it
this way.

I do have a hackish way of doing it by using the preferences tag and
getting the path to the image, and then having a script copy it over, but I
know the better way to do it would be to just make a tag to take care of
images that are not going to be the main icon or splash image and have
cordova-cli handle it for me when I call cordova prepare.

This isn't really for a plugin, though maybe an app template, but I just
wanted to add this functionality to be able to specify non-icon and
non-splash images through the config.xml.

I've found where in cordova-lib that the parsing happens for the icon and
splash tags, so I was proposing to add a new tag for general images. The
images could be anything that a user might want in his or her app. An
example would be a customized button. The user can specify the path to the
image file, and then the image will be dropped into the drawable directory.

On Fri, May 1, 2015 at 12:27 PM, Jesse purplecabb...@gmail.com wrote:

 What is the use for the images? Is this for a plugin, or an app template?
 I can think of a couple ways to do this, but none would affect
 configure.xml.
 I suggest you look at how the splash screen plugin does this for android.



  On May 1, 2015, at 8:39 AM, Karen Tran ktop...@gmail.com wrote:
 
  Hi dev-list,
 
  I wanted to get your input on a feature I want to add to the config.xml.
 
  Currently there are only the icon tag and splash tag that allows the user
  to specify the icon and splash image in the config.xml respectively.
 
  I want to be able to specify multiple images that will be used in my app
  such as customized buttons. The problem is that the icon tag will rename
  the image specified to icon.png, so ultimately the user would only be
 able
  to change the main icon. And the splash tag of course handles the splash
  image, so I don't want that.
 
  I propose making a new tag that handles general images. It'll be similar
 to
  the icon tag, except it won't rename the image. It will copy the image
 from
  the src, and drop it into the correct drawable-density directory (I am
  working in android).
 
  I know I can just drop the images myself into the drawable folders, but I
  have to assume that my users won't know the android project structure and
  will only modify the config.xml.
 
  Any thoughts, comments, or critiques would be appreciated.
 
 
  Regards,
  Karen Tran

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

[Proposal - New Feature] Add tag to config.xml to handle images

[Karen Tran]

Hi dev-list,

I wanted to get your input on a feature I want to add to the config.xml.

Currently there are only the icon tag and splash tag that allows the user
to specify the icon and splash image in the config.xml respectively.

I want to be able to specify multiple images that will be used in my app
such as customized buttons. The problem is that the icon tag will rename
the image specified to icon.png, so ultimately the user would only be able
to change the main icon. And the splash tag of course handles the splash
image, so I don't want that.

I propose making a new tag that handles general images. It'll be similar to
the icon tag, except it won't rename the image. It will copy the image from
the src, and drop it into the correct drawable-density directory (I am
working in android).

I know I can just drop the images myself into the drawable folders, but I
have to assume that my users won't know the android project structure and
will only modify the config.xml.

Any thoughts, comments, or critiques would be appreciated.


Regards,
Karen Tran