Comment distinguons-Nous Jamais Demandé D'Arrêter, en Demandant en Android M de l'Exécution des Autorisations?
Quand il s'agit de la M Developer Preview d'exécution des autorisations, selon Google:
-
Si vous n'avez jamais demandé une certaine permission avant, il suffit de demander pour elle
-
Si vous avez demandé avant, et que l'utilisateur dit "non", et que l'utilisateur tente alors de faire quelque chose qui doit être rejeté autorisation, vous devez demander à l'utilisateur d'expliquer pourquoi vous avez besoin de la permission, avant de passer à demander la permission à nouveau
-
Si vous avez demandé à un couple de fois avant, et que l'utilisateur a dit: "non, et cesse de demander" (via la case à cocher sur l'exécution de l'autorisation de dialogue), vous devriez juste arrêter de déranger (par exemple, désactiver l'INTERFACE utilisateur qui nécessite l'autorisation de l'auteur)
Cependant, nous n'avons qu'une seule méthode, shouldShowRequestPermissionRationale()
, de retour d'un boolean
, et nous avons trois états. Nous avons besoin d'une façon de distinguer les jamais demandé de l'état de l'arrêt-demander à l'état, alors que nous false
de shouldShowRequestPermissionRationale()
pour les deux.
Pour les autorisations demandées lors de la première exécution de l'application, ce n'est pas un gros problème. Il y a beaucoup de recettes pour déterminer qu'il s'agit probablement de la première exécution de votre application (par exemple, boolean
valeur dans SharedPreferences
), et afin de vous supposer que si c'est la première exécution de votre application, vous vous êtes jamais demandé de l'état.
Toutefois, une partie de la vision de l'exécution des autorisations est que vous ne pourriez pas demander à tous d'entre eux à l'avant. Les autorisations liées à frange fonctionnalités vous pouvez seulement demander pour plus tard, lorsque l'utilisateur appuie sur quelque chose qui nécessite l'autorisation. Ici, l'application peut avoir été exécuté plusieurs fois, pendant des mois, avant de nous tout d'un coup besoin de demander une autre autorisation.
Dans ces cas, sommes-nous censés si oui ou non nous avons demandé la permission de nous-mêmes? Ou est-il quelque chose dans l'Android M API qui me manque qui nous dit que si nous avons demandé ou non?
- C'est toutes les infos que j'ai eu, même chose que ce que tu viens de poster plus.google.com/+BenjaminWeiss/posts/PFSd7wau4n8
- L'exemple d'application est donc trivial et incomplète, elle pourrait tout aussi bien ne pas exister.
- Donc meilleure supposition est pour stocker une valeur de type boolean dans SharedPreferences par l'autorisation, ou de toute autre artefact, qui était Google recommandation at IO.
- Ma préoccupation est la possibilité de la
SharedPreferences
sortir de la synchronisation avec Android stockée informations d'autorisation. Android est le "système d'enregistrement" en ce qui concerne d'exécution des autorisations. Il a clairement l'information, car sinon il ne pourrait jamais revenirtrue
deshouldShowRequestPermissionRationale()
. Je suis juste de voir si il y a un peu de méthode, qui a ajouté que je suis absent, c'est tout. - Connaissant Google, ils vont railler
shouldShowRequestPermissionRationale()
en 6.1 et ajouter une nouvelle méthode qui renvoie unint
. - Il n'est pas arrivé 🙁
Vous devez vous connecter pour publier un commentaire.
Comme par l'exemple actuel: https://github.com/googlesamples/android-RuntimePermissions/blob/master/Application/src/main/java/com/example/android/system/runtimepermissions/MainActivity.java#L195
Stocker une valeur de type boolean dans SharedPreferences avec la clé que votre code d'autorisation et de valeur, comme indiqué ci-dessus, pour indiquer si la préférence a été refusée avant.
Malheureusement, vous ne pouvez probablement pas de contre-vérifier une préférence qui a été accepté et a nié plus tard pendant que votre application est en cours d'exécution. La finale de la spec n'est pas disponible, mais il ya une chance que votre application obtient redémarré ou se moquer des valeurs jusqu'à ce que le prochain lancement.
Je sais que je suis un affichage très fin, mais l'exemple détaillé peut être utile pour quelqu'un.
Ce que j'ai remarqué, c'est que, si nous vérifions les shouldShowRequestPermissionRationale() drapeau de onRequestPermissionsResult() la méthode de rappel, il montre que les deux états.
État 1:-Retourner la valeur true:-- Tout moment, l'utilisateur clique sur Refuser des autorisations (y compris la première fois.
État 2:-Retourne false :- si l'utilisateur sélectionne s “ne demande jamais de nouveau.
Voici un exemple avec plusieurs de demande d'autorisation:-
L'application a besoin de 2 autorisations au démarrage . SEND_SMS et ACCESS_FINE_LOCATION (les deux sont mentionnés dans manifest.xml).
Dès que l'application démarre, il vous demande de plusieurs autorisations ensemble. Si les deux autorisations sont accordées le flux normal va.
Dans le cas où une ou plusieurs autorisations ne sont pas accordées,
activityCompat.requestPermissions() va demander des autorisations et le contrôle va à onRequestPermissionsResult() la méthode de rappel.
Vous devez vérifier la valeur de shouldShowRequestPermissionRationale() drapeau en onRequestPermissionsResult() la méthode de rappel.
Il y a seulement deux cas:--
Cas 1:-chaque fois que l'utilisateur clique sur Refuser des autorisations (y compris la première fois), elle retournera true. Ainsi, lorsque l'utilisateur refuse, nous pouvons montrer plus d'explication et de garder demandant de nouveau.
Cas 2:-Seulement si l'utilisateur sélectionne “ne demande jamais de nouveau”, il retournera false. Dans ce cas, nous pouvons continuer avec des fonctionnalités limitées et guide de l'utilisateur pour activer les autorisations de paramètres pour plus de fonctionnalités, ou nous pouvons terminer l'installation, si les autorisations sont triviales pour l'application.
CAS - 1
CAS - 2
for (int i = 0; i < permissions.length; i++)
Non, vous n'avez pas besoin de savoir si ou de ne pas avoir demandé la permission, et vous n'avez pas besoin de distinguer Jamais Demandé D'Arrêter, Poser.
L'état 1 et 3 sont les mêmes pour le développeur de l'application: vous avez besoin de la permission et
ActivityCompat.checkSelfPermission != PackageManager.PERMISSION_GRANTED
, alors que vous venez de demander la permission viaActivityCompat.requestPermissions()
, chaque fois que l'utilisateur a appuyé sur l'fonctionnalité qui nécessite l'autorisation, peu importe combien de fois vous avez demandé. L'utilisateur finira par "Subvention" ou "Refuser" avec "ne jamais demander de nouveau" est cochée. La conception ne PAS vous décourager de popup la demande d'autorisation dialogbox plusieurs fois.Cependant, le design ne vous encourageons à expliquer l'objet de l'autorisation à un certain point votre état 2.
shouldShowRequestPermissionRationale()
n'est PAS utilisé pour déterminer si vous devez demander la permission, il est utilisé pour déterminer si vous devez afficher des explications, AVANT de vous demander la permission.Un couple de plus d'explication quant à l'état 3:
shouldShowRequestPermissionRationale()
.ActivityCompat.requestPermissions()
ne sera pas de popup dialogbox plus.shouldShowRequestPermissionRationale()
de retour faux.shouldShowRequestPermissionRationale()
semble être de retour la valeur attendue déjà dansonRequestPermissionsResult()
, de sorte que si l'utilisateur a refusé avec ne-demander-encore une fois,shouldShowRequestPermissionRationale()
, en effet, de retourfalse
. Donc, si vous voulez avoir la même réponse (par exemple, afficher un snack-bar), indépendamment de si l'utilisateur a juste refusé à ne pas demander de nouveau ou qui l'a fait précédemment, vous n'avez pas besoin de l'état 1. Si vous voulez des réponses différentes (par exemple, afficher uniquement un snack-bar si l'utilisateur a refusé avec ne-demander-encore une fois il y a quelques temps, et pas seulement maintenant), vous auriez encore besoin de l'état 1.shouldShowRequestPermissionRationale()
sera de retourfalse
si vous n'avez jamais montré la boîte de dialogue autorisation avant, même si l'utilisateur n'a pas refusé la permission avant. Donc, la première fois, vous devez la force de la boîte de dialogue autorisation et puis vous pouvez compter sur cela. Prenez en compte que ce comportement peut changer dans le futur.J'ai une approche de la solution à votre problème, il semble fonctionner assez bien pour moi.
Je distingue Jamais Demandé D'Arrêter, en Demandant l'aide de la SharedPreferences, je vais vous donner un exemple de la façon dont je l'utiliser.
Ici, c'est la méthode pour le suivi de la boîte de dialogue autorisation a été montré première fois, lorsque l'utilisateur a coché la jamais demander à nouveau et lorsque l'autorisation est directement refusé après que l'utilisateur est vérifié jamais demander à nouveau pour cela nous avons besoin de garder un drapeau si l'autorisation justification de la boîte de dialogue a été montré avant de se faire entraîner dans onRequestPermissionsResult.
Appel de la méthode checkPermission() lorsque requis.
Après avoir essayé toutes les réponses ici et certains autres post sur internet. Je sais que je dois utiliser un sharedPreference
isLocationPermissionDialogShown
(false par défaut) et tout fonctionne comme prévu par.shouldShowRequestPermissionRationale
retournefalse
etisLocationPermissionDialogShown
aussifalse
shouldShowRequestPermissionRationale
retourtrue
et tout en montrant un dialogue nous avons misisLocationPermissionDialogShown
àtrue
. et quand nous vérifier l'état des deux seratrue
shouldShowRequestPermissionRationale
retourtrue
etisLocationPermissionDialogShown
retournetrue
shouldShowRequestPermissionRationale
retourfalse
etisLocationPermissionDialogShown
retournetrue
. Ce dont nous avons besoin.Veuillez vérifier exemple.
Espère que cela aidera.
Flux d'affaires:-
1. Lorsque l'utilisateur clique sur "refuser la permission" pour la première fois, je vais vous montrer justification de la boîte de dialogue pour expliquer la nécessité de l'autorisation. Ensuite, si l'utilisateur clique sur le bouton "annuler" sur la justification de la boîte de dialogue, je vais vous montrer un toast d'afficher le message "Veuillez donner la permission à obtenir la localisation".
2. Après cela, lorsque l'utilisateur clique sur refuser l'autorisation(ne pas demander de nouveau) sur la boîte de dialogue autorisations, je vais vous montrer un message "Veuillez indiquer l'emplacement de l'autorisation de paramètres de l'application". Vous remarquerez que j'ai ajouté les mots "à partir des paramètres de l'application" parce que l'utilisateur a coché la case "ne pas demander de nouveau".
3. Donc à partir de maintenant sur la boîte de dialogue autorisation ne sera pas montré.Aussi le justification de la boîte de dialogue ne s'affichera pas.
Donc, la clé ici est que si les deux d'autorisation de dialogue et de justification de la boîte de dialogue n'apparaît pas, cela signifie que l'utilisateur a coché la case "ne pas demander de nouveau" case à cocher.
Le code:-
Vérifier ce référentiel:
https://github.com/debChowdhury/PermissionHelperEasy
Vous pouvez regarder ici - il y a un organigramme qui explique le processus tout à fait bonne. Elle explique aussi quand vous devez l'appeler
shouldShowRequestPermissionRationale()
et quand elle retourne true.Fondamentalement selon Android documentation, vous devriez toujours demander la permission si vous ne l'avez pas (Android retournera automatiquement REFUSÉE dans le rappel si l'utilisateur a dit de ne jamais demander à nouveau) et vous devez afficher un court message si l'utilisateur a déjà refusé une fois dans le passé, mais n'a pas marqué la jamais demander à nouveau l'option.
Il n'est pas nécessaire de mettre en parallèle un état persistant de l'autorisation de l'état, vous pouvez simplement utiliser cette méthode qui renvoie l'autorisation de l'état à tout moment:
Mise en garde: retourne BLOQUÉ la première application de début, avant que l'utilisateur a accepté/refusé l'autorisation par l'utilisateur invite (sur sdk 23+ périphériques)
J'ai aussi utilisé cette réponse est ici.
getPermissionStatus
, à tort, de retourBLOCKED
, qui est en fait pas vrai. Un 4e état est nécessaire dans cette conception, probablement appeléHAVENT_ASKED
, et le seul moyen de détecter ce qui est par l'utilisation d'un partagées pref ou quelque chose de similaire.