[Interest] Android: Better way of asserting permanent permission refusal

[René Hansen]

Well, yes, I know what rationale means, but the method only takes one
parameter, *permission*, which I assume aligns with requestPermissions,
e.g. "android.permission.ACCESS_FINE_LOCATION", so how is the text for a
*rationale* actually provided? I don't get it.


/René

On Wed, 27 Jun 2018 at 18:01 Jason H <jhihn at gmx.com> wrote:

> The rationale is the justification to the user on why they should grant
> the permission
> "Location needed for GPS tagging"
> "Camera needed for selfies"
>
> The "UI" is operating system grant dialog.
>
>
> *Sent:* Tuesday, June 26, 2018 at 5:02 PM
> *From:* "René Hansen" <renehh at gmail.com>
> *To:* "Pierre-Yves Siret" <py.siret at gmail.com>
> *Cc:* interest <interest at qt-project.org>
> *Subject:* Re: [Interest] Android: Better way of asserting permanent
> permission refusal
> All things happen for a reason. :)
>
> My rationale, is that I have a feature which is location based. I want to
> be able to let the user toggle the feature on/off via a switch on a
> settings page. In the case where a user has permanently deactivated
> location permissions for the app, I want this switch to equally be
> disabled, with a message instructing the user to edit global permissions,
> if they wish to use the feature.
>
> I haven't tried out *shouldShowRequestPermissionRationale*, since I don't
> really understand what it does from the docs.
>
> "Returns true if you should show UI with a rationale for requesting a
> permission."
>
> I mean... What rationale? What UI?
>
>
> /René
>
> On Tue, 26 Jun 2018 at 15:05 Pierre-Yves Siret <py.siret at gmail.com> wrote:
>
>> 2018-06-26 13:27 GMT+02:00 René Hansen <renehh at gmail.com>:
>>
>>> Hi,
>>>
>>>
>>> When requesting specific permissions through
>>> QtAndroid::requestPermissions{,Sync}, the host native permissions popup has
>>> the option to "Don't show this again", on subsequent requests, which will
>>> permanently disable the popups on future invocations.
>>>
>>> From then on a permission can only be given through host sytem global
>>> settings.
>>>
>>> The question then becomes, is there a canonical way to figure out, if
>>> the user has ticked the "Don't show again" for a specific permission?
>>>
>>> Right now I've resorted to heuristic, where I time the response of the
>>> permissions request. Typically it comes back in < 150 msec, when it has
>>> been perma-denied, and the fastest I've been able to allow or deny it via
>>> the popup was about 900 msec. I've placed my guesstimate predicate at 400
>>> msec, to allow a bit of margin for error on slower devices.
>>>
>>> But... this seems like such a bad hack.
>>>
>>> Can anyone tell me of a better way to do this?
>>>
>>>
>>> Best regards,
>>>
>>> René Hansen
>>>
>> _______________________________________________
>>> Interest mailing list
>>> Interest at qt-project.org
>>> http://lists.qt-project.org/mailman/listinfo/interest
>>>
>>
>> Hello,
>>
>> The better way is not do it.
>> This Qt API just mirrors the Android API, and there is no native way to
>> know if the user selected "Don't show this again" previously. At least not
>> without calling requestPermissions.
>>
>> Why do you want to check this?
>> If you want to show a rationale to thw user about why the app need a
>> permission, you can use QtAndroid::shouldShowRequestPermissionRationale.
>> It will return true if the user previously denied the permission without
>> selecting the "Don't show this again" option.
>>
>> Regards,
>> Pierre-Yves Siret
>>
>>
> _______________________________________________ Interest mailing list
> Interest at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20180627/567291f0/attachment.html>