Re: [Vote] 5.0.0 Windows Release
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&data=02%7C01%7Cv-alsoro% > 40microsoft.com%7C > 27147ccdfdcc4e8d12ab08d45046afec%7C72f988bf86f141af91ab2d7cd011 > db47%7C1%7C0% > 7C636221711911814136&sdata=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&data= > 02%7C01%7Cv-alsoro%40 > microsoft.com%7C27147ccdfdcc4e8d12ab08d45046afec% > 7C72f988bf86f141af91ab2d7cd > 011db47%7C1%7C0%7C636221711911814136&sdata= > EBwPD3j4cb9idteUka7BZzpVVPgXZfkE9 > NhTnRbsuDk%3D&reserved=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&data=02%7C01%7Cv-alsoro% > 40microsoft.com%7 > C27147ccdfdcc4e8d12ab08d45046afec%7C72f988bf86f141af91ab2d7cd011 > db47%7C1%7C0 > %7C636221711911814136&sdata=2nyElr3rLRACU1mp%2B9CeCepjep8% > 2BTERrLaZWCZSdX%2B > 0%3D&reserved=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&data=02%7 > C01%7Cv-alsoro%40microsoft.com%7C27147ccdfdcc4e8d12ab08d45046 > afec%7C72f988bf > 86f141af91ab2d7cd011db47%7C1%7C0%7C636221711911814136& > sdata=wZ3BZYdWUF7%2BB0 > PzVrlR%2B1dQAd0LcsL%2Bxa9nQXqY2wo%3D&reserved=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
+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
+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&data=02%7C01%7Cv-seshak%40microsoft.com% > 7Ce8e7ef34878d497246e008d4299f662b%7C72f988bf86f141af91ab2d7cd011 > db47%7C1%7C0%7C636179211969896647&sdata=HkZ%2FmT9ZCcsvLyP3GuqtD% > 2FZQxyhybaiYA%2BLCrYjBVaU%3D&reserved=0 > - https://na01.safelinks.protection.outlook.com/?url= > https%3A%2F%2Fgithub.com%2Fapache%2Fcordova-lib%2Fpull% > 2F509&data=02%7C01%7Cv-seshak%40microsoft.com% > 7Ce8e7ef34878d497246e008d4299f662b%7C72f988bf86f141af91ab2d7cd011 > db47%7C1%7C0%7C636179211969896647&sdata=Aj7muzsOli2qEnuPHyintdelemmsZo > lLlHcTp%2FB9U5E%3D&reserved=0 > - https://na01.safelinks.protection.outlook.com/?url= > https%3A%2F%2Fgithub.com%2Fapache%2Fcordova-lib%2Fpull% > 2F513&data=02%7C01%7Cv-seshak%40microsoft.com% > 7Ce8e7ef34878d497246e008d4299f662b%7C72f988bf86f141af91ab2d7cd011 > db47%7C1%7C0%7C636179211969896647&sdata=J3huQ2NR7Zq9JbVsGbzcSqCIsPmGP% > 2FIgRJx8VKxuha8%3D&reserved=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
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?
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" 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 wrote: > > > +1 sounds good > > > > On Thu, Dec 8, 2016 at 4:36 PM, Karen Tran > 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&data=02%7C01%7Cv-vlkoti%40microsoft.com% > 7Cfd5830ed12474774b88d08d422b3a5de%7C72f988bf86f141af91ab2d7cd011 > db47%7C1%7C0%7C636171602363520388&sdata=QYSHbcwPFrPlhItNTNMHYifiuzXo5u > 9nzOt3Z0tuZ%2FQ%3D&reserved=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 > > > changed at all).
Re: [DISCUSSION] Windows tag, what should it be doing?
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 wrote: > +1 sounds good > > On Thu, Dec 8, 2016 at 4:36 PM, Karen Tran 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 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. > > >
Re: [DISCUSSION] Windows tag, what should it be doing?
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 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 > 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 >> doi
Re: [DISCUSSION] Windows tag, what should it be doing?
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 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&data=02%7C01%7CTim.Barham%40microsoft.com% > 7C8aad7996a77c4232984008d41aff194c%7C72f988bf86f141af91ab2d7cd011 > db47%7C1%7C0%7C636163130331524841&sdata=xMO4L% > 2B2JBIy5LERs2JJeT6tjaJweSOfX8HAb9kdTvfU%3D&reserved=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 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&data=02%7C01%7CTim.Barham%40mi > > crosoft.com%7C8aad7996a77c4232984008d41aff194c%7C72f988bf86f141af91ab2 > > d7cd011db47%7C1%7C0%7C636163130331524841&sdata=UoNsuqqH3EYZjTSZgDQkv1q > > 49XuAGwoUXyWp8OfxjyI%3D&reserved=0 > > > > On Fri, Dec 2, 2016 at 11:27 AM, Kerri Shotts > > 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, a
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://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 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 > 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 > > 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 : > > > > > >> 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 > 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?
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
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
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 > > > > > > 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&data=01%7c01%7cnikhilkh%40microsoft.com%7c379bf4c2d > > > ae > > > 4454ee13008d369539a2b%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=T > > > vJ lf2LDyl%2bfSbRMDPjmLe%2fMBQf7PnAzRao5QANRrH4%3d > > > > > > On Tue, Apr 5, 2016 at 6:51 PM, Carlos Santana > > > > > > wrote: > > > > > > > Oh so it means you don't want
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 > > 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&data=01%7c01%7cnikhilkh%40microsoft.com%7c379bf4c2dae > > 4454ee13008d369539a2b%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=TvJ > > lf2LDyl%2bfSbRMDPjmLe%2fMBQf7PnAzRao5QANRrH4%3d > > > > 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 > > > > https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fhi > > > > .im%2fsimonmacdonald&data=01%7c01%7cnikhilkh%40microsoft.com%7c379 > > > > bf4c2dae4454ee13008d369539a2b%7c72f988bf86f141af91ab2d7cd011db47%7 > > > > c1&sdata=TvJlf2LDyl%2bfSbRMDPjmLe%2fMBQf7PnAzRao5QANRrH4%3d > > > > > > > > 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://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2 > > > &
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: ** *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 > > > > plugin.xml > > > > > > we > > > > > > > > > should > > > > > > > > > > not bui
Re: [Android] 5.0.x release branch?
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&data=01%7c01%7cnikhilkh%40microsoft.com%7c1785194b1f82494fc2d908d2c2c99f36%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=%2fPKmL8KTsz5dnC3A75yMatXLQUnfK0Nv07%2bve4PVcCE%3d > > > > > https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithub.com%2finfil00p%2fcordova-plugin-geolocation%2ftree%2fsmores&data=01%7c01%7cnikhilkh%40microsoft.com%7c1785194b1f82494fc2d908d2c2c99f36%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=o6cLXM4f3kpUGCTlIv65ft8lKv6pc5qbeY%2bdUxiP4bc%3d > > > > > https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithub.com%2finfil00p%2fcordova-plugin-camera%2ftree%2fsmores&data=01%7c01%7
Re: Marshmallow Update and Cordova-Android 5.0
I tested your camera plugin through mobilespec and the permissions are working. On Thu, Sep 3, 2015 at 12:10 PM, Joe Bowser wrote: > On Thu, Sep 3, 2015 at 8:07 AM Karen Tran 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 > > 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: Marshmallow Update and Cordova-Android 5.0
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
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 wrote: > On Thu, Aug 20, 2015 at 9:28 PM Karen Tran 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 fi
Android Marshmallow Permissions
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
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 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 > 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 wrote: > > > > > Sent you the test app off-list. > > > > > > On Wed, Jul 15, 2015 at 11:12 AM Andrew Grieve > > > 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 > 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
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 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 > 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 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: > > > > > > > > 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 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. >
Re: [Proposal - New Feature] Add tag to config.xml to handle images
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: 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 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 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 > > 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 > > 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 > > > > > > > > > > >
Re: [Proposal - New Feature] Add tag to config.xml to handle images
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 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 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
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
Introduction
Hello, My name is Karen. I am a new addition to the Cordova team at IBM and will be focusing on android. I spent the last month learning about cordova and working through a few issues so I look forward to contributing soon. Regards, Karen Tran
