cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon MacDonald <>
Subject Re: [Android] Oops...we screwed up in Cordova-Android 5.0.x
Date Mon, 30 Nov 2015 20:43:41 GMT
Hey Joe,

My opinion is as long as we are not introducing a breaking change we don't
need to jump to 6.0.0. If we need to add a new method then we can probably
just bump it to 5.1.0.

If you need an extra pair of hands to update the plugins just let me know.

On Nov 30, 2015 04:21, "Terence M. Bandoian" <> wrote:

> Do it right.  Damn the fallout.
> -Terence
> On 11/27/2015 4:51 PM, Joe Bowser wrote:
>> Hey
>> So, I just came back from Android Dev Summit, and it turns out that we
>> didn't figure out how to use the
>> method shouldShowRequestPermissionRationale().  Here's the use case that
>> we
>> didn't figure out:
>> If a user refuses a permission twice, they have the option of not showing
>> the permission prompt ever again.  Basically, this is bad, and the user
>> should probably use the first callback to explain why this is an issue.
>> That said, if the user requests the permission a second time, Android Best
>> Practices state that we should call shouldShowRequestPermissionRationale()
>> and check to see if it was refused the first time, explain that the
>> permission requires this permission, and then prompt.
>> Right now, we can't do that easily without adding an additional API call
>> on
>> the CordovaInterface.  I think that any changes to CordovaInterface should
>> automatically prompt a major version update, so I don't want to do this.
>> So, what should we do with this call? Ignore it? Call it inside the
>> plugin,
>> and have each plugin handle this independently?  I think that we should
>> have probably caught this when we were wishing we could explain why we
>> were
>> requesting certain permissions on our plugins, but hindsight is always
>> 20/20.
>> So, thoughts on what we should do about this?  Make do without it?
>> Joe
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message