Nightly build #44 for cordova has succeeded!

2016-06-17 Thread Apache Jenkins Server 
Nightly build #44 for cordova has succeeded!
The latest nightly has been published and you can try it out with 'npm i -g 
cordova@nightly'

For details check build console at 
https://builds.apache.org/job/cordova-nightly/44/consoleFull

-
Jenkins for Apache Cordova

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

[GitHub] cordova-plugin-camera issue #219: Dont work camera on Android

2016-06-17 Thread cleever 
Github user cleever commented on the issue:

https://github.com/apache/cordova-plugin-camera/pull/219
  
Thank you @thedoorbell 


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

Re: [Discuss] Why was device.name removed from the device-plugin?

2016-06-17 Thread Carlos Santana 
I think this belongs in user community plugin

maybe a cordova-plugin-device-nickname 

- Carlos Santana
@csantanapr

> On Jun 17, 2016, at 10:25 PM, Kerri Shotts  wrote:
> 
> -1 to using Bluetooth to get the device name. That would add an additional 
> permission (AFAICT) that is hard to justify to an end user, and which would 
> be added to a good number of Cordova apps intending only to use the device 
> plugin to implement platform-specific features or workarounds. 
> I agree with Joe -- this is best in a separate plugin. That give the dev a 
> choice if they can justify the extra permission, and the potential headache 
> that comes with arbitrary device names (or lack thereof). 
> My two cents, anyway. :)
> ~Kerri
>

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

Re: [Discuss] Why was device.name removed from the device-plugin?

2016-06-17 Thread Kerri Shotts 
-1 to using Bluetooth to get the device name. That would add an additional 
permission (AFAICT) that is hard to justify to an end user, and which would be 
added to a good number of Cordova apps intending only to use the device plugin 
to implement platform-specific features or workarounds. 
I agree with Joe -- this is best in a separate plugin. That give the dev a 
choice if they can justify the extra permission, and the potential headache 
that comes with arbitrary device names (or lack thereof). 
My two cents, anyway. :)
~Kerri

Re: [Discuss] Why was device.name removed from the device-plugin?

2016-06-17 Thread Joe Bowser 
The Bluetooth plugin, or a third party plugin.  It does not belong in
Device.

On Fri, Jun 17, 2016, 5:23 PM Philipp Kursawe 
wrote:

> > that might bring some trouble if the device doesn't have
> bluetooth. We should decide what to return in that case, nothing? and
> document it
>
> We return manufactur + model in that case.
>
> @Joe: the devices I checked had pretty useful BT sharing names. And it is
> functionality belonging to the device. Where else would it belong to?
>
> On Sat, Jun 18, 2016 at 12:42 AM, Joe Bowser  wrote:
>
> > -1
> >
> > This is a new feature and something we never supported.
> >
> > The model feature was the user-readable type of phone on Android (i.e.
> > Nexus 5X) where the name was the in-house codename for it, in this case
> > bullhead.  When we switched to device.model, we removed device.name.
> > Getting the Bluetooth sharing name could literally be anything like
> > "MyHovercraftIsFullOfEels" or "ThisRentalCarSucks".
> >
> > This is entirely new functionality, and I think that it should exist in a
> > separate plugin.
> >
> >
> >
> > On Fri, Jun 17, 2016 at 3:25 PM, julio cesar sanchez <
> > jcesarmob...@gmail.com
> > > wrote:
> >
> > > +1
> > >
> > > The only thing I see is the plugin he points get the android name from
> > the
> > > bluetooth adapter, that might bring some trouble if the device doesn't
> > have
> > > bluetooth. We should decide what to return in that case, nothing? and
> > > document it
> > >
> > > 2016-06-18 0:15 GMT+02:00 Shazron :
> > >
> > > > I have no objection if the API property is unambiguous, unlike what
> it
> > > was
> > > > before (over 4 years ago!), and is supported by all the major
> platforms
> > > > (looks like it is, from what you mentioned). Also -- Ubuntu/Linux
> looks
> > > > like its just /etc/hostname. We'll just have to bump a minor version.
> > > >
> > > > What do the others think?
> > > >
> > > >
> > > >
> > > > On Fri, Jun 17, 2016 at 3:07 PM, Philipp Kursawe <
> > phil.kurs...@gmail.com
> > > >
> > > > wrote:
> > > >
> > > > > To further emphasize one point. I fully agree with moving from
> > > > device.name
> > > > > to device.model + device.manufacturer + device.platform.
> > > > > But I still ask all of you do consider bringing back a proper
> > > > device.name.
> > > > > As I wrote, on Windows its pretty easy to get the real name of the
> > > > > PC/Phone. On iOS and Android the work is already done.
> > > > >
> > > > > On Sat, Jun 18, 2016 at 12:02 AM, Philipp Kursawe <
> > > > phil.kurs...@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > Thanks for pointing this out. However the name is not used to
> > > reference
> > > > > > the device to the API. Thats what the device.uuid is being used
> > for.
> > > > The
> > > > > > device name is used in the UI where the user can see its API
> > enabled
> > > > > > devices. You don't want to show the user the device id there
> (cause
> > > she
> > > > > has
> > > > > > no point of reference to which physical device it belongs) but
> the
> > > name
> > > > > she
> > > > > > gave her phone and knows her phone when she connects it to
> itunes,
> > > > iphoto
> > > > > > etc.
> > > > > >
> > > > > > So the reason to introduce the name property back is exactly the
> > one
> > > > you
> > > > > > mentioned: The user can always change the name of her phone and
> > there
> > > > > knows
> > > > > > its name and will recognize it in a list of devices.
> > > > > >
> > > > > > On Fri, Jun 17, 2016 at 9:23 PM, Shazron 
> > wrote:
> > > > > >
> > > > > >> Hi Philipp,
> > > > > >> This was the rationale:
> > > > > >>
> > > > > >>
> > > > >
> > > >
> > >
> >
> https://lists.apache.org/thread.html/e3b0e5f87ba3929d5578308b25ee9a6af5b91177b94015878970fa8e@1352248856@%3Cdev.cordova.apache.org%3E
> > > > > >>
> > > > > >> On iOS,  [UIDevice name] returns the name the user sets in
> iTunes
> > > for
> > > > > >> their
> > > > > >> device i.e. "Shazron's iPhone 4", and can change anytime so
> > relying
> > > on
> > > > > it
> > > > > >> for API access would be problematic.
> > > > > >>
> > > > > >>
> > > > > >> On Fri, Jun 17, 2016 at 1:51 AM, Philipp Kursawe <
> > > > > phil.kurs...@gmail.com>
> > > > > >> wrote:
> > > > > >>
> > > > > >> > I wonder why such an important piece of information is not
> > > provided
> > > > > >> anymore
> > > > > >> > in the device plugin?
> > > > > >> > What was the reason to remove the property?
> > > > > >> >
> > > > > >> > The name of the device, especially when users can
> > authorise/revoke
> > > > API
> > > > > >> > access to apps on different devices, is an important variable
> to
> > > > know.
> > > > > >> >
> > > > > >> > There is a plugin that brings back this functionality for
> > Android,
> > > > iOS
> > > > > >> and
> > > > > >> > for Windows it would be a one-liner only too.
> > > > > >> > https://github.com/becvert/cordova-plugin-device-name
> > > > > >> >
> > > > > >>
> > >

Re: [Discuss] Why was device.name removed from the device-plugin?

2016-06-17 Thread Philipp Kursawe 
> that might bring some trouble if the device doesn't have
bluetooth. We should decide what to return in that case, nothing? and
document it

We return manufactur + model in that case.

@Joe: the devices I checked had pretty useful BT sharing names. And it is
functionality belonging to the device. Where else would it belong to?

On Sat, Jun 18, 2016 at 12:42 AM, Joe Bowser  wrote:

> -1
>
> This is a new feature and something we never supported.
>
> The model feature was the user-readable type of phone on Android (i.e.
> Nexus 5X) where the name was the in-house codename for it, in this case
> bullhead.  When we switched to device.model, we removed device.name.
> Getting the Bluetooth sharing name could literally be anything like
> "MyHovercraftIsFullOfEels" or "ThisRentalCarSucks".
>
> This is entirely new functionality, and I think that it should exist in a
> separate plugin.
>
>
>
> On Fri, Jun 17, 2016 at 3:25 PM, julio cesar sanchez <
> jcesarmob...@gmail.com
> > wrote:
>
> > +1
> >
> > The only thing I see is the plugin he points get the android name from
> the
> > bluetooth adapter, that might bring some trouble if the device doesn't
> have
> > bluetooth. We should decide what to return in that case, nothing? and
> > document it
> >
> > 2016-06-18 0:15 GMT+02:00 Shazron :
> >
> > > I have no objection if the API property is unambiguous, unlike what it
> > was
> > > before (over 4 years ago!), and is supported by all the major platforms
> > > (looks like it is, from what you mentioned). Also -- Ubuntu/Linux looks
> > > like its just /etc/hostname. We'll just have to bump a minor version.
> > >
> > > What do the others think?
> > >
> > >
> > >
> > > On Fri, Jun 17, 2016 at 3:07 PM, Philipp Kursawe <
> phil.kurs...@gmail.com
> > >
> > > wrote:
> > >
> > > > To further emphasize one point. I fully agree with moving from
> > > device.name
> > > > to device.model + device.manufacturer + device.platform.
> > > > But I still ask all of you do consider bringing back a proper
> > > device.name.
> > > > As I wrote, on Windows its pretty easy to get the real name of the
> > > > PC/Phone. On iOS and Android the work is already done.
> > > >
> > > > On Sat, Jun 18, 2016 at 12:02 AM, Philipp Kursawe <
> > > phil.kurs...@gmail.com>
> > > > wrote:
> > > >
> > > > > Thanks for pointing this out. However the name is not used to
> > reference
> > > > > the device to the API. Thats what the device.uuid is being used
> for.
> > > The
> > > > > device name is used in the UI where the user can see its API
> enabled
> > > > > devices. You don't want to show the user the device id there (cause
> > she
> > > > has
> > > > > no point of reference to which physical device it belongs) but the
> > name
> > > > she
> > > > > gave her phone and knows her phone when she connects it to itunes,
> > > iphoto
> > > > > etc.
> > > > >
> > > > > So the reason to introduce the name property back is exactly the
> one
> > > you
> > > > > mentioned: The user can always change the name of her phone and
> there
> > > > knows
> > > > > its name and will recognize it in a list of devices.
> > > > >
> > > > > On Fri, Jun 17, 2016 at 9:23 PM, Shazron 
> wrote:
> > > > >
> > > > >> Hi Philipp,
> > > > >> This was the rationale:
> > > > >>
> > > > >>
> > > >
> > >
> >
> https://lists.apache.org/thread.html/e3b0e5f87ba3929d5578308b25ee9a6af5b91177b94015878970fa8e@1352248856@%3Cdev.cordova.apache.org%3E
> > > > >>
> > > > >> On iOS,  [UIDevice name] returns the name the user sets in iTunes
> > for
> > > > >> their
> > > > >> device i.e. "Shazron's iPhone 4", and can change anytime so
> relying
> > on
> > > > it
> > > > >> for API access would be problematic.
> > > > >>
> > > > >>
> > > > >> On Fri, Jun 17, 2016 at 1:51 AM, Philipp Kursawe <
> > > > phil.kurs...@gmail.com>
> > > > >> wrote:
> > > > >>
> > > > >> > I wonder why such an important piece of information is not
> > provided
> > > > >> anymore
> > > > >> > in the device plugin?
> > > > >> > What was the reason to remove the property?
> > > > >> >
> > > > >> > The name of the device, especially when users can
> authorise/revoke
> > > API
> > > > >> > access to apps on different devices, is an important variable to
> > > know.
> > > > >> >
> > > > >> > There is a plugin that brings back this functionality for
> Android,
> > > iOS
> > > > >> and
> > > > >> > for Windows it would be a one-liner only too.
> > > > >> > https://github.com/becvert/cordova-plugin-device-name
> > > > >> >
> > > > >>
> > > > >
> > > > >
> > > >
> > >
> >
>

Re: [Discuss] Why was device.name removed from the device-plugin?

2016-06-17 Thread Joe Bowser 
-1

This is a new feature and something we never supported.

The model feature was the user-readable type of phone on Android (i.e.
Nexus 5X) where the name was the in-house codename for it, in this case
bullhead.  When we switched to device.model, we removed device.name.
Getting the Bluetooth sharing name could literally be anything like
"MyHovercraftIsFullOfEels" or "ThisRentalCarSucks".

This is entirely new functionality, and I think that it should exist in a
separate plugin.



On Fri, Jun 17, 2016 at 3:25 PM, julio cesar sanchez  wrote:

> +1
>
> The only thing I see is the plugin he points get the android name from the
> bluetooth adapter, that might bring some trouble if the device doesn't have
> bluetooth. We should decide what to return in that case, nothing? and
> document it
>
> 2016-06-18 0:15 GMT+02:00 Shazron :
>
> > I have no objection if the API property is unambiguous, unlike what it
> was
> > before (over 4 years ago!), and is supported by all the major platforms
> > (looks like it is, from what you mentioned). Also -- Ubuntu/Linux looks
> > like its just /etc/hostname. We'll just have to bump a minor version.
> >
> > What do the others think?
> >
> >
> >
> > On Fri, Jun 17, 2016 at 3:07 PM, Philipp Kursawe  >
> > wrote:
> >
> > > To further emphasize one point. I fully agree with moving from
> > device.name
> > > to device.model + device.manufacturer + device.platform.
> > > But I still ask all of you do consider bringing back a proper
> > device.name.
> > > As I wrote, on Windows its pretty easy to get the real name of the
> > > PC/Phone. On iOS and Android the work is already done.
> > >
> > > On Sat, Jun 18, 2016 at 12:02 AM, Philipp Kursawe <
> > phil.kurs...@gmail.com>
> > > wrote:
> > >
> > > > Thanks for pointing this out. However the name is not used to
> reference
> > > > the device to the API. Thats what the device.uuid is being used for.
> > The
> > > > device name is used in the UI where the user can see its API enabled
> > > > devices. You don't want to show the user the device id there (cause
> she
> > > has
> > > > no point of reference to which physical device it belongs) but the
> name
> > > she
> > > > gave her phone and knows her phone when she connects it to itunes,
> > iphoto
> > > > etc.
> > > >
> > > > So the reason to introduce the name property back is exactly the one
> > you
> > > > mentioned: The user can always change the name of her phone and there
> > > knows
> > > > its name and will recognize it in a list of devices.
> > > >
> > > > On Fri, Jun 17, 2016 at 9:23 PM, Shazron  wrote:
> > > >
> > > >> Hi Philipp,
> > > >> This was the rationale:
> > > >>
> > > >>
> > >
> >
> https://lists.apache.org/thread.html/e3b0e5f87ba3929d5578308b25ee9a6af5b91177b94015878970fa8e@1352248856@%3Cdev.cordova.apache.org%3E
> > > >>
> > > >> On iOS,  [UIDevice name] returns the name the user sets in iTunes
> for
> > > >> their
> > > >> device i.e. "Shazron's iPhone 4", and can change anytime so relying
> on
> > > it
> > > >> for API access would be problematic.
> > > >>
> > > >>
> > > >> On Fri, Jun 17, 2016 at 1:51 AM, Philipp Kursawe <
> > > phil.kurs...@gmail.com>
> > > >> wrote:
> > > >>
> > > >> > I wonder why such an important piece of information is not
> provided
> > > >> anymore
> > > >> > in the device plugin?
> > > >> > What was the reason to remove the property?
> > > >> >
> > > >> > The name of the device, especially when users can authorise/revoke
> > API
> > > >> > access to apps on different devices, is an important variable to
> > know.
> > > >> >
> > > >> > There is a plugin that brings back this functionality for Android,
> > iOS
> > > >> and
> > > >> > for Windows it would be a one-liner only too.
> > > >> > https://github.com/becvert/cordova-plugin-device-name
> > > >> >
> > > >>
> > > >
> > > >
> > >
> >
>

Re: [Discuss] Why was device.name removed from the device-plugin?

2016-06-17 Thread julio cesar sanchez 
+1

The only thing I see is the plugin he points get the android name from the
bluetooth adapter, that might bring some trouble if the device doesn't have
bluetooth. We should decide what to return in that case, nothing? and
document it

2016-06-18 0:15 GMT+02:00 Shazron :

> I have no objection if the API property is unambiguous, unlike what it was
> before (over 4 years ago!), and is supported by all the major platforms
> (looks like it is, from what you mentioned). Also -- Ubuntu/Linux looks
> like its just /etc/hostname. We'll just have to bump a minor version.
>
> What do the others think?
>
>
>
> On Fri, Jun 17, 2016 at 3:07 PM, Philipp Kursawe 
> wrote:
>
> > To further emphasize one point. I fully agree with moving from
> device.name
> > to device.model + device.manufacturer + device.platform.
> > But I still ask all of you do consider bringing back a proper
> device.name.
> > As I wrote, on Windows its pretty easy to get the real name of the
> > PC/Phone. On iOS and Android the work is already done.
> >
> > On Sat, Jun 18, 2016 at 12:02 AM, Philipp Kursawe <
> phil.kurs...@gmail.com>
> > wrote:
> >
> > > Thanks for pointing this out. However the name is not used to reference
> > > the device to the API. Thats what the device.uuid is being used for.
> The
> > > device name is used in the UI where the user can see its API enabled
> > > devices. You don't want to show the user the device id there (cause she
> > has
> > > no point of reference to which physical device it belongs) but the name
> > she
> > > gave her phone and knows her phone when she connects it to itunes,
> iphoto
> > > etc.
> > >
> > > So the reason to introduce the name property back is exactly the one
> you
> > > mentioned: The user can always change the name of her phone and there
> > knows
> > > its name and will recognize it in a list of devices.
> > >
> > > On Fri, Jun 17, 2016 at 9:23 PM, Shazron  wrote:
> > >
> > >> Hi Philipp,
> > >> This was the rationale:
> > >>
> > >>
> >
> https://lists.apache.org/thread.html/e3b0e5f87ba3929d5578308b25ee9a6af5b91177b94015878970fa8e@1352248856@%3Cdev.cordova.apache.org%3E
> > >>
> > >> On iOS,  [UIDevice name] returns the name the user sets in iTunes for
> > >> their
> > >> device i.e. "Shazron's iPhone 4", and can change anytime so relying on
> > it
> > >> for API access would be problematic.
> > >>
> > >>
> > >> On Fri, Jun 17, 2016 at 1:51 AM, Philipp Kursawe <
> > phil.kurs...@gmail.com>
> > >> wrote:
> > >>
> > >> > I wonder why such an important piece of information is not provided
> > >> anymore
> > >> > in the device plugin?
> > >> > What was the reason to remove the property?
> > >> >
> > >> > The name of the device, especially when users can authorise/revoke
> API
> > >> > access to apps on different devices, is an important variable to
> know.
> > >> >
> > >> > There is a plugin that brings back this functionality for Android,
> iOS
> > >> and
> > >> > for Windows it would be a one-liner only too.
> > >> > https://github.com/becvert/cordova-plugin-device-name
> > >> >
> > >>
> > >
> > >
> >
>

Re: [Discuss] Why was device.name removed from the device-plugin?

2016-06-17 Thread Jesse 
It makes sense as long as it is considered user meta, and nothing else. 

> On Jun 17, 2016, at 3:15 PM, Shazron  wrote:
> 
> I have no objection if the API property is unambiguous, unlike what it was
> before (over 4 years ago!), and is supported by all the major platforms
> (looks like it is, from what you mentioned). Also -- Ubuntu/Linux looks
> like its just /etc/hostname. We'll just have to bump a minor version.
> 
> What do the others think?
> 
> 
> 
> On Fri, Jun 17, 2016 at 3:07 PM, Philipp Kursawe 
> wrote:
> 
>> To further emphasize one point. I fully agree with moving from device.name
>> to device.model + device.manufacturer + device.platform.
>> But I still ask all of you do consider bringing back a proper device.name.
>> As I wrote, on Windows its pretty easy to get the real name of the
>> PC/Phone. On iOS and Android the work is already done.
>> 
>> On Sat, Jun 18, 2016 at 12:02 AM, Philipp Kursawe 
>> wrote:
>> 
>>> Thanks for pointing this out. However the name is not used to reference
>>> the device to the API. Thats what the device.uuid is being used for. The
>>> device name is used in the UI where the user can see its API enabled
>>> devices. You don't want to show the user the device id there (cause she
>> has
>>> no point of reference to which physical device it belongs) but the name
>> she
>>> gave her phone and knows her phone when she connects it to itunes, iphoto
>>> etc.
>>> 
>>> So the reason to introduce the name property back is exactly the one you
>>> mentioned: The user can always change the name of her phone and there
>> knows
>>> its name and will recognize it in a list of devices.
>>> 
 On Fri, Jun 17, 2016 at 9:23 PM, Shazron  wrote:
 
 Hi Philipp,
 This was the rationale:
>> https://lists.apache.org/thread.html/e3b0e5f87ba3929d5578308b25ee9a6af5b91177b94015878970fa8e@1352248856@%3Cdev.cordova.apache.org%3E
 
 On iOS,  [UIDevice name] returns the name the user sets in iTunes for
 their
 device i.e. "Shazron's iPhone 4", and can change anytime so relying on
>> it
 for API access would be problematic.
 
 
 On Fri, Jun 17, 2016 at 1:51 AM, Philipp Kursawe <
>> phil.kurs...@gmail.com>
 wrote:
 
> I wonder why such an important piece of information is not provided
 anymore
> in the device plugin?
> What was the reason to remove the property?
> 
> The name of the device, especially when users can authorise/revoke API
> access to apps on different devices, is an important variable to know.
> 
> There is a plugin that brings back this functionality for Android, iOS
 and
> for Windows it would be a one-liner only too.
> https://github.com/becvert/cordova-plugin-device-name
>> 

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

Re: [Discuss] Why was device.name removed from the device-plugin?

2016-06-17 Thread Shazron 
I have no objection if the API property is unambiguous, unlike what it was
before (over 4 years ago!), and is supported by all the major platforms
(looks like it is, from what you mentioned). Also -- Ubuntu/Linux looks
like its just /etc/hostname. We'll just have to bump a minor version.

What do the others think?



On Fri, Jun 17, 2016 at 3:07 PM, Philipp Kursawe 
wrote:

> To further emphasize one point. I fully agree with moving from device.name
> to device.model + device.manufacturer + device.platform.
> But I still ask all of you do consider bringing back a proper device.name.
> As I wrote, on Windows its pretty easy to get the real name of the
> PC/Phone. On iOS and Android the work is already done.
>
> On Sat, Jun 18, 2016 at 12:02 AM, Philipp Kursawe 
> wrote:
>
> > Thanks for pointing this out. However the name is not used to reference
> > the device to the API. Thats what the device.uuid is being used for. The
> > device name is used in the UI where the user can see its API enabled
> > devices. You don't want to show the user the device id there (cause she
> has
> > no point of reference to which physical device it belongs) but the name
> she
> > gave her phone and knows her phone when she connects it to itunes, iphoto
> > etc.
> >
> > So the reason to introduce the name property back is exactly the one you
> > mentioned: The user can always change the name of her phone and there
> knows
> > its name and will recognize it in a list of devices.
> >
> > On Fri, Jun 17, 2016 at 9:23 PM, Shazron  wrote:
> >
> >> Hi Philipp,
> >> This was the rationale:
> >>
> >>
> https://lists.apache.org/thread.html/e3b0e5f87ba3929d5578308b25ee9a6af5b91177b94015878970fa8e@1352248856@%3Cdev.cordova.apache.org%3E
> >>
> >> On iOS,  [UIDevice name] returns the name the user sets in iTunes for
> >> their
> >> device i.e. "Shazron's iPhone 4", and can change anytime so relying on
> it
> >> for API access would be problematic.
> >>
> >>
> >> On Fri, Jun 17, 2016 at 1:51 AM, Philipp Kursawe <
> phil.kurs...@gmail.com>
> >> wrote:
> >>
> >> > I wonder why such an important piece of information is not provided
> >> anymore
> >> > in the device plugin?
> >> > What was the reason to remove the property?
> >> >
> >> > The name of the device, especially when users can authorise/revoke API
> >> > access to apps on different devices, is an important variable to know.
> >> >
> >> > There is a plugin that brings back this functionality for Android, iOS
> >> and
> >> > for Windows it would be a one-liner only too.
> >> > https://github.com/becvert/cordova-plugin-device-name
> >> >
> >>
> >
> >
>

Re: [Discuss] Why was device.name removed from the device-plugin?

2016-06-17 Thread Philipp Kursawe 
To further emphasize one point. I fully agree with moving from device.name
to device.model + device.manufacturer + device.platform.
But I still ask all of you do consider bringing back a proper device.name.
As I wrote, on Windows its pretty easy to get the real name of the
PC/Phone. On iOS and Android the work is already done.

On Sat, Jun 18, 2016 at 12:02 AM, Philipp Kursawe 
wrote:

> Thanks for pointing this out. However the name is not used to reference
> the device to the API. Thats what the device.uuid is being used for. The
> device name is used in the UI where the user can see its API enabled
> devices. You don't want to show the user the device id there (cause she has
> no point of reference to which physical device it belongs) but the name she
> gave her phone and knows her phone when she connects it to itunes, iphoto
> etc.
>
> So the reason to introduce the name property back is exactly the one you
> mentioned: The user can always change the name of her phone and there knows
> its name and will recognize it in a list of devices.
>
> On Fri, Jun 17, 2016 at 9:23 PM, Shazron  wrote:
>
>> Hi Philipp,
>> This was the rationale:
>>
>> https://lists.apache.org/thread.html/e3b0e5f87ba3929d5578308b25ee9a6af5b91177b94015878970fa8e@1352248856@%3Cdev.cordova.apache.org%3E
>>
>> On iOS,  [UIDevice name] returns the name the user sets in iTunes for
>> their
>> device i.e. "Shazron's iPhone 4", and can change anytime so relying on it
>> for API access would be problematic.
>>
>>
>> On Fri, Jun 17, 2016 at 1:51 AM, Philipp Kursawe 
>> wrote:
>>
>> > I wonder why such an important piece of information is not provided
>> anymore
>> > in the device plugin?
>> > What was the reason to remove the property?
>> >
>> > The name of the device, especially when users can authorise/revoke API
>> > access to apps on different devices, is an important variable to know.
>> >
>> > There is a plugin that brings back this functionality for Android, iOS
>> and
>> > for Windows it would be a one-liner only too.
>> > https://github.com/becvert/cordova-plugin-device-name
>> >
>>
>
>

Re: [Discuss] Why was device.name removed from the device-plugin?

2016-06-17 Thread Philipp Kursawe 
Thanks for pointing this out. However the name is not used to reference the
device to the API. Thats what the device.uuid is being used for. The device
name is used in the UI where the user can see its API enabled devices. You
don't want to show the user the device id there (cause she has no point of
reference to which physical device it belongs) but the name she gave her
phone and knows her phone when she connects it to itunes, iphoto etc.

So the reason to introduce the name property back is exactly the one you
mentioned: The user can always change the name of her phone and there knows
its name and will recognize it in a list of devices.

On Fri, Jun 17, 2016 at 9:23 PM, Shazron  wrote:

> Hi Philipp,
> This was the rationale:
>
> https://lists.apache.org/thread.html/e3b0e5f87ba3929d5578308b25ee9a6af5b91177b94015878970fa8e@1352248856@%3Cdev.cordova.apache.org%3E
>
> On iOS,  [UIDevice name] returns the name the user sets in iTunes for their
> device i.e. "Shazron's iPhone 4", and can change anytime so relying on it
> for API access would be problematic.
>
>
> On Fri, Jun 17, 2016 at 1:51 AM, Philipp Kursawe 
> wrote:
>
> > I wonder why such an important piece of information is not provided
> anymore
> > in the device plugin?
> > What was the reason to remove the property?
> >
> > The name of the device, especially when users can authorise/revoke API
> > access to apps on different devices, is an important variable to know.
> >
> > There is a plugin that brings back this functionality for Android, iOS
> and
> > for Windows it would be a one-liner only too.
> > https://github.com/becvert/cordova-plugin-device-name
> >
>

Re: Contribution for improve Cordova

2016-06-17 Thread Shazron 
Welcome!
Check out the contribution guide [1] and let us know if you need any help
in this regard. Also, please subscribe to this list by sending an email to
dev-subscr...@cordova.apache.org

[1] http://cordova.apache.org/contribute/



On Fri, Jun 17, 2016 at 3:43 AM, sanjeewa kumara 
wrote:

> I'm a under graduate computer student  at the Faulty of Engineering,
> University of Peradeniya. I am interesting to contribute to open
> source product. I am trying to fix bugs in Cordova.
> Here, I attache my LinkedIn profile :
> https://www.linkedin.com/in/sanjeewa-kumara-481a1766?trk=hp-identity-name
>
> Thank you.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>
>

Contribution for improve Cordova

2016-06-17 Thread sanjeewa kumara 
I'm a under graduate computer student  at the Faulty of Engineering,
University of Peradeniya. I am interesting to contribute to open
source product. I am trying to fix bugs in Cordova.
Here, I attache my LinkedIn profile :
https://www.linkedin.com/in/sanjeewa-kumara-481a1766?trk=hp-identity-name

Thank you.

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

Re: [Discuss] Why was device.name removed from the device-plugin?

2016-06-17 Thread Shazron 
Hi Philipp,
This was the rationale:
https://lists.apache.org/thread.html/e3b0e5f87ba3929d5578308b25ee9a6af5b91177b94015878970fa8e@1352248856@%3Cdev.cordova.apache.org%3E

On iOS,  [UIDevice name] returns the name the user sets in iTunes for their
device i.e. "Shazron's iPhone 4", and can change anytime so relying on it
for API access would be problematic.


On Fri, Jun 17, 2016 at 1:51 AM, Philipp Kursawe 
wrote:

> I wonder why such an important piece of information is not provided anymore
> in the device plugin?
> What was the reason to remove the property?
>
> The name of the device, especially when users can authorise/revoke API
> access to apps on different devices, is an important variable to know.
>
> There is a plugin that brings back this functionality for Android, iOS and
> for Windows it would be a one-liner only too.
> https://github.com/becvert/cordova-plugin-device-name
>

[GitHub] cordova-docs pull request #612: CB-11412 Added docs for template use and cre...

2016-06-17 Thread carynbear 
GitHub user carynbear opened a pull request:

https://github.com/apache/cordova-docs/pull/612

CB-11412 Added docs for template use and create



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/carynbear/cordova-docs CB-11412

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/cordova-docs/pull/612.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #612


commit cbf0b722b22b8e445db1f1517de279134f6436c0
Author: carynbear 
Date:   2016-06-17T17:53:55Z

CB-11412 Added docs for template use and create




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

[GitHub] cordova-plugin-media pull request #102: CB-11430 Report duration's NaN value...

2016-06-17 Thread vladimir-kotikov 
GitHub user vladimir-kotikov opened a pull request:

https://github.com/apache/cordova-plugin-media/pull/102

CB-11430 Report duration's NaN value to JS properly



### Platforms affected
iOS

### What does this PR do?
Fixes incorrect duration value reported to JavaScript when media stream 
duration is infinite

### What testing has been done on this change?
Manual testing + plugin automated tests

### Checklist
- [X] [ICLA](http://www.apache.org/licenses/icla.txt) has been signed and 
submitted to secret...@apache.org.
- [X] [Reported an issue](http://cordova.apache.org/contribute/issues.html) 
in the JIRA database
- [X] Commit message follows the format: "CB-3232: (android) Fix bug with 
resolving file paths", where CB- is the JIRA ID & "android" is the platform 
affected.
- [ ] Added automated test coverage as appropriate for this change.



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/vladimir-kotikov/cordova-plugin-media CB-11430

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/cordova-plugin-media/pull/102.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #102


commit d30da8c10655b869528466b0ebd0a2cbff0f4c03
Author: Vladimir Kotikov 
Date:   2016-06-17T13:53:29Z

CB-11430 Report duration NaN value to JS properly




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

[GitHub] cordova-plugin-dialogs issue #71: Secure prompt text fields for passwords

2016-06-17 Thread pke 
Github user pke commented on the issue:

https://github.com/apache/cordova-plugin-dialogs/pull/71
  
@purplecabbage no, of course one would still support the old signature and 
emit a deprecation warning. Inspecting the arguments should be pretty easy in 
that case. If the second argument is not a function but an object then its the 
new syntax.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

[GitHub] cordova-plugin-dialogs issue #71: Secure prompt text fields for passwords

2016-06-17 Thread purplecabbage 
Github user purplecabbage commented on the issue:

https://github.com/apache/cordova-plugin-dialogs/pull/71
  
True. But all existing code would break. 


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

[GitHub] cordova-plugin-dialogs issue #71: Secure prompt text fields for passwords

2016-06-17 Thread pke 
Github user pke commented on the issue:

https://github.com/apache/cordova-plugin-dialogs/pull/71
  
Instead of adding yet another argument one could also opt to support an 
`option` object instead/alternatively.
Especially since all those values are optional anyway the API surface would 
get a lot cleaner `prompt(message, options)`


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

[GitHub] cordova-lib issue #260: CB-9371: Fix prepare deleting orientation preference...

2016-06-17 Thread cjpearson 
Github user cjpearson commented on the issue:

https://github.com/apache/cordova-lib/pull/260
  
@shazron, could you please take a look at this PR?


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

[GitHub] cordova-lib issue #260: CB-9371: Fix prepare deleting orientation preference...

2016-06-17 Thread mattrayner 
Github user mattrayner commented on the issue:

https://github.com/apache/cordova-lib/pull/260
  
I'm guessing there's no news on this?


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

[GitHub] cordova-plugin-media issue #101: CB-11409: (iOS) New method allowing to disa...

2016-06-17 Thread cordova-qa 
Github user cordova-qa commented on the issue:

https://github.com/apache/cordova-plugin-media/pull/101
  
Cordova CI Build has one or more failures. 

**Commit** - 
[Link](https://github.com/apache/cordova-plugin-media/pull/101/commits/eca1d6342cdda64d73235b1ae5658bc87619ba54)
**Dashboard** - 
[Link](http://cordova-ci.cloudapp.net:8080/job/cordova-plugin-media-pr/39/)

| Builder Name  | Console Output | Test Report | Device Logs  |
| :---: | :---:  |   :---: | :---:|
| [Windows 8.1 Store]( 
http://cordova-ci.cloudapp.net:8080/job/cordova-plugin-media-pr/39//PLATFORM=windows-8.1-store/)
 | [Link]( 
http://cordova-ci.cloudapp.net:8080/job/cordova-plugin-media-pr/39//PLATFORM=windows-8.1-store/console)
 | [Link]( 
http://cordova-ci.cloudapp.net:8080/job/cordova-plugin-media-pr/39//PLATFORM=windows-8.1-store/testReport/)
 | [Link]( 
http://cordova-ci.cloudapp.net:8080/job/cordova-plugin-media-pr/39//PLATFORM=windows-8.1-store/artifact/)
 |
| [Windows 10  Store]( 
http://cordova-ci.cloudapp.net:8080/job/cordova-plugin-media-pr/39//PLATFORM=windows-10-store/)
 | [Link]( 
http://cordova-ci.cloudapp.net:8080/job/cordova-plugin-media-pr/39//PLATFORM=windows-10-store/console)
 | [Link]( 
http://cordova-ci.cloudapp.net:8080/job/cordova-plugin-media-pr/39//PLATFORM=windows-10-store/testReport/)
 | [Link]( 
http://cordova-ci.cloudapp.net:8080/job/cordova-plugin-media-pr/39//PLATFORM=windows-10-store/artifact/)
 |
| [Windows 8.1 Phone]( 
http://cordova-ci.cloudapp.net:8080/job/cordova-plugin-media-pr/39//PLATFORM=windows-8.1-phone/)
 | [Link]( 
http://cordova-ci.cloudapp.net:8080/job/cordova-plugin-media-pr/39//PLATFORM=windows-8.1-phone/console)
 | [Link]( 
http://cordova-ci.cloudapp.net:8080/job/cordova-plugin-media-pr/39//PLATFORM=windows-8.1-phone/testReport/)
 | [Link]( 
http://cordova-ci.cloudapp.net:8080/job/cordova-plugin-media-pr/39//PLATFORM=windows-8.1-phone/artifact/)
 |
| [iOS]( 
http://cordova-ci.cloudapp.net:8080/job/cordova-plugin-media-pr/39//PLATFORM=ios/)
 | [Link]( 
http://cordova-ci.cloudapp.net:8080/job/cordova-plugin-media-pr/39//PLATFORM=ios/console)
 | [Link]( 
http://cordova-ci.cloudapp.net:8080/job/cordova-plugin-media-pr/39//PLATFORM=ios/testReport/)
 | [Link]( 
http://cordova-ci.cloudapp.net:8080/job/cordova-plugin-media-pr/39//PLATFORM=ios/artifact/)
 |
| [Android]( 
http://cordova-ci.cloudapp.net:8080/job/cordova-plugin-media-pr/39//PLATFORM=android/)
 | [Link]( 
http://cordova-ci.cloudapp.net:8080/job/cordova-plugin-media-pr/39//PLATFORM=android/console)
 | [Link]( 
http://cordova-ci.cloudapp.net:8080/job/cordova-plugin-media-pr/39//PLATFORM=android/testReport/)
 | [Link]( 
http://cordova-ci.cloudapp.net:8080/job/cordova-plugin-media-pr/39//PLATFORM=android/artifact/)
 |
 



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

[GitHub] cordova-plugin-media pull request #101: CB-11409: (iOS) New method allowing ...

2016-06-17 Thread tbrebant 
GitHub user tbrebant opened a pull request:

https://github.com/apache/cordova-plugin-media/pull/101

CB-11409: (iOS) New method allowing to disable automated memory release on 
memoryWarning

### Platforms affected

iOS

### What does this PR do?

It is adding a method allowing the user to disable (and re-enable) the 
automated resource releasing when a memory warning is received on iOS. Why? 
Because user may want to handle memory warnings by himself (such as releasing 
other less important resource first).

This method is static, on the class:

```js
Media.shouldReleaseOnMemoryWarning(false);
// Here comes custom code to handle memoryWarnings
```

### What testing has been done on this change?

- Played multiple (non streaming) audio files after having disabled the 
auto-release and while having some heavy memory process running, until a 
memoryWarning is received: audio continue to play.
- Played multiple (non streaming) audio files with the auto-release enabled 
and while having some heavy memory process running, until a memoryWarning is 
received: audio stops.

Ran the integrated tests. Before doing any change (version 2.3.1-dev) the 
result was:

![cordova-media-plugin 2 3 
1-dev](https://cloud.githubusercontent.com/assets/637734/16145899/3ca50f5a-34b6-11e6-924c-f04b87e7a1d1.jpg)

After the change the result is exactly the same:


![img_0194](https://cloud.githubusercontent.com/assets/637734/16145928/57cf7b9e-34b6-11e6-94a5-e44a38068688.jpg)

All tests was made with an iPad2 on iOS8.4.

### Checklist
- [x] [ICLA](http://www.apache.org/licenses/icla.txt) has been signed and 
submitted to secret...@apache.org.
- [x] [Reported an issue](http://cordova.apache.org/contribute/issues.html) 
in the JIRA database
- [x] Commit message follows the format: "CB-3232: (android) Fix bug with 
resolving file paths", where CB- is the JIRA ID & "android" is the platform 
affected.
- [ ] Added automated test coverage as appropriate for this change.

About the last point: tests will come as soon as possible, meanwhile please 
have a look at the code and review it! Thank you.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/tbrebant/cordova-plugin-media CB11409

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/cordova-plugin-media/pull/101.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #101


commit eca1d6342cdda64d73235b1ae5658bc87619ba54
Author: tbrebant 
Date:   2016-06-14T09:09:54Z

CB-11409: (iOS) Added a method to disable automated memory releasing when a 
memoryWarning is received




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

[Discuss] Why was device.name removed from the device-plugin?

2016-06-17 Thread Philipp Kursawe 
I wonder why such an important piece of information is not provided anymore
in the device plugin?
What was the reason to remove the property?

The name of the device, especially when users can authorise/revoke API
access to apps on different devices, is an important variable to know.

There is a plugin that brings back this functionality for Android, iOS and
for Windows it would be a one-liner only too.
https://github.com/becvert/cordova-plugin-device-name

[GitHub] cordova-plugin-media issue #100: CB-7684: (iOS) Fix CDVSound killing all aud...

2016-06-17 Thread cordova-qa 
Github user cordova-qa commented on the issue:

https://github.com/apache/cordova-plugin-media/pull/100
  
Cordova CI Build has one or more failures. 

**Commit** - 
[Link](https://github.com/apache/cordova-plugin-media/pull/100/commits/40a561d87fcebb5114fbdc01e6dafd6c617956fc)
**Dashboard** - 
[Link](http://cordova-ci.cloudapp.net:8080/job/cordova-plugin-media-pr/38/)

| Builder Name  | Console Output | Test Report | Device Logs  |
| :---: | :---:  |   :---: | :---:|
| [Windows 8.1 Store]( 
http://cordova-ci.cloudapp.net:8080/job/cordova-plugin-media-pr/38//PLATFORM=windows-8.1-store/)
 | [Link]( 
http://cordova-ci.cloudapp.net:8080/job/cordova-plugin-media-pr/38//PLATFORM=windows-8.1-store/console)
 | [Link]( 
http://cordova-ci.cloudapp.net:8080/job/cordova-plugin-media-pr/38//PLATFORM=windows-8.1-store/testReport/)
 | [Link]( 
http://cordova-ci.cloudapp.net:8080/job/cordova-plugin-media-pr/38//PLATFORM=windows-8.1-store/artifact/)
 |
| [Windows 10  Store]( 
http://cordova-ci.cloudapp.net:8080/job/cordova-plugin-media-pr/38//PLATFORM=windows-10-store/)
 | [Link]( 
http://cordova-ci.cloudapp.net:8080/job/cordova-plugin-media-pr/38//PLATFORM=windows-10-store/console)
 | [Link]( 
http://cordova-ci.cloudapp.net:8080/job/cordova-plugin-media-pr/38//PLATFORM=windows-10-store/testReport/)
 | [Link]( 
http://cordova-ci.cloudapp.net:8080/job/cordova-plugin-media-pr/38//PLATFORM=windows-10-store/artifact/)
 |
| [Windows 8.1 Phone]( 
http://cordova-ci.cloudapp.net:8080/job/cordova-plugin-media-pr/38//PLATFORM=windows-8.1-phone/)
 | [Link]( 
http://cordova-ci.cloudapp.net:8080/job/cordova-plugin-media-pr/38//PLATFORM=windows-8.1-phone/console)
 | [Link]( 
http://cordova-ci.cloudapp.net:8080/job/cordova-plugin-media-pr/38//PLATFORM=windows-8.1-phone/testReport/)
 | [Link]( 
http://cordova-ci.cloudapp.net:8080/job/cordova-plugin-media-pr/38//PLATFORM=windows-8.1-phone/artifact/)
 |
| [iOS]( 
http://cordova-ci.cloudapp.net:8080/job/cordova-plugin-media-pr/38//PLATFORM=ios/)
 | [Link]( 
http://cordova-ci.cloudapp.net:8080/job/cordova-plugin-media-pr/38//PLATFORM=ios/console)
 | [Link]( 
http://cordova-ci.cloudapp.net:8080/job/cordova-plugin-media-pr/38//PLATFORM=ios/testReport/)
 | [Link]( 
http://cordova-ci.cloudapp.net:8080/job/cordova-plugin-media-pr/38//PLATFORM=ios/artifact/)
 |
| [Android]( 
http://cordova-ci.cloudapp.net:8080/job/cordova-plugin-media-pr/38//PLATFORM=android/)
 | [Link]( 
http://cordova-ci.cloudapp.net:8080/job/cordova-plugin-media-pr/38//PLATFORM=android/console)
 | [Link]( 
http://cordova-ci.cloudapp.net:8080/job/cordova-plugin-media-pr/38//PLATFORM=android/testReport/)
 | [Link]( 
http://cordova-ci.cloudapp.net:8080/job/cordova-plugin-media-pr/38//PLATFORM=android/artifact/)
 |
 



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

[GitHub] cordova-plugin-media pull request #100: CB-7684: (iOS) Fix CDVSound killing ...

2016-06-17 Thread tbrebant 
GitHub user tbrebant opened a pull request:

https://github.com/apache/cordova-plugin-media/pull/100

CB-7684: (iOS) Fix CDVSound killing all audio when a single file finishes

### Platforms affected

iOS

### What does this PR do?

We arrived to the same conclusion as Nathan Stryker on Jira 
(https://issues.apache.org/jira/browse/CB-7684) and @ionut-movila in the PR 
https://github.com/apache/cordova-plugin-media/pull/33 : all `self.avSession 
setActive:NO` should be removed.

The problem was not only that when a media finishes it is stopping other 
ones played by the plugin, but it is also killing any sound played by another 
plugin or by WebView's default webaudio system, triggering a descriptive:
```
AVAudioSession.mm:646: -[AVAudioSession setActive:withOptions:error:]: 
Deactivating an audio session that has running I/O. All I/O should be stopped 
or paused prior to deactivating the audio session.
```
We found that `AVAudioSession` is a singleton for the whole app (cf. 
https://developer.apple.com/library/ios/documentation/AVFoundation/Reference/AVAudioSession_ClassReference/).

Apple says:

> Most apps never need to deactivate their audio session explicitly. 
Important exceptions include VoIP (Voice over Internet Protocol) apps, 
turn-by-turn navigation apps, and, in some cases, recording apps.

(cf. 
https://developer.apple.com/library/ios/documentation/Audio/Conceptual/AudioSessionProgrammingGuide/ConfiguringanAudioSession/ConfiguringanAudioSession.html)

### What testing has been done on this change?

- Played multiple sounds (non streaming) with the plugin, then waited for 
one to stop: it is not stopping other sounds anymore.
- Played multiple sounds (non streaming) with the plugin, then stopped one 
and released it: it is not stopping other sounds anymore.
- Played a sound (non streaming) with the plugin and another one via 
webview's webaudio, then waited the one played by the plugin to end: it is not 
stopping other sounds anymore.
- Played a sound (non streaming) with the plugin and another one via 
webview's webaudio, then stopped and released the one played by the plugin: it 
is not stopping other sounds anymore.
- Checked all possibilities with Xcode monitoring application: no memory 
issue detected.

Ran the integrated tests. Before doing any change (version 2.3.1-dev) the 
result was:

![cordova-media-plugin 2 3 
1-dev](https://cloud.githubusercontent.com/assets/637734/16144330/252582c8-34ad-11e6-9932-cdb8ce8e05e5.jpg)

After the change the result is exactly the same:

![cordova-media-plugin 
cb-7684](https://cloud.githubusercontent.com/assets/637734/16144343/35490008-34ad-11e6-98bd-90d7c86becc3.jpg)

Before merging, it would be great if someone can test:
- an application using the recording feature
- an application using the streaming feature

### Checklist
- [x] [ICLA](http://www.apache.org/licenses/icla.txt) has been signed and 
submitted to secret...@apache.org.
- [x] [Reported an issue](http://cordova.apache.org/contribute/issues.html) 
in the JIRA database
- [x] Commit message follows the format: "CB-3232: (android) Fix bug with 
resolving file paths", where CB- is the JIRA ID & "android" is the platform 
affected.
- [ ] Added automated test coverage as appropriate for this change.

About the last point: I don't see what kind of tests we can add for this 
fix.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/tbrebant/cordova-plugin-media CB7684

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/cordova-plugin-media/pull/100.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #100


commit 40a561d87fcebb5114fbdc01e6dafd6c617956fc
Author: tbrebant 
Date:   2016-06-10T07:35:01Z

CB-7684: (iOS) Fix CDVSound killing all audio when a single file finishes




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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