0

How are we supposed to handle, when a user denies the permission request for kCLAuthorizationStatusAuthorizedAlways ? As i understand it, we don't get a direct response to requestAlwaysAuthorization, but rather we have to register a callback for locationManagerDidChangeAuthorization, which only gets called, if status is undetermined or is changed. Since we first have to request whenInUse permission with requestWhenInUseAuthorization, the status is no longer undetermined once we request always permission. Furthermore, since the "deny" option is "keep when in use permission", the actual permission is not changed if the request is denied, hence the callback won't be called. So how are we supposed to know the request was denied by the user, so we can point them towards the settings ?

A bit of context: I am developing an App in Flutter, where I need the kCLAuthorizationStatusAuthorizedAlways. For this, I use a library called permission_handler, which has native (objective c) code for iOS. Sadly, it has a bug, and since I need it to work, I am going to try to fix it myself.

Looking through the code, I suspect the problem stems from the callback not being called in the "deny" case, so I am trying to figure out how to obtain the information, that the request was denied, so I can return this information from the plugin to the FlutterEngine, where my flutter code is run.

You don't have to understand any Flutter or Dart to explain/understand this, as I just want to know how you would handle this situation in a native iOS app, so I can understand it and apply that knowledge to my flutter app/the library.

Thanks for taking the time to read my question and helping me!

Lukas Kurz
  • 85
  • 9
  • "hence the callback won't be called" Yes it will. – matt Feb 26 '22 at 14:31
  • @matt Really ? Am i missing something in the [documentation](https://developer.apple.com/documentation/corelocation/cllocationmanagerdelegate/3563956-locationmanagerdidchangeauthoriz?language=objc) here then ? Do you know what the status would then be in this case ? Since it already is `whenInUse`, it would be called with `whenInUse` again, would it not ? – Lukas Kurz Feb 26 '22 at 14:41
  • It is already `.notDetermined`. After showing the user the authorization, it _cannot_ be `.notDetermined`. Therefore it has changed. – matt Feb 26 '22 at 15:23
  • When you ask for "always" permission, the user sees a request for "when in use". If the approve this, then your app sees that it has "always" permission (via the callback), but this "provisional always"; your app doesn't actually get location updates when it is in the background (unless you hav explicitly requested background updates). When the user is subsequently prompted to allow "always" they can respond "yes" in which case you don't see a status change but your app gets background location updates – Paulw11 Feb 26 '22 at 20:02
  • If they respond with the "keep while using" then your app will get a permission callback indicating that it now has "when in use" permission. So your app can't know if it has provisional always vs real always but it can know if it has explicit "when in use". Your app can also ask for "when in use" and if the user approves, then ask for "always" to trigger the upgrade dialog. – Paulw11 Feb 26 '22 at 20:04
  • @Paulw11 your approach with the double dialog is how it is described/recommended by the library and also implemented by me therefore. This is where my issue stems from, the absence of a callback/response when the upgrade dialog is denied. This results (in the library) in a callback, which is never called and on the next permission request, the library thinks there is still a permission request ongoing... – Lukas Kurz Feb 27 '22 at 12:58
  • A possible solution for this, would be to listen to UIApplicationDidBecomeActiveNotification, as a sort of alternative callback, letting me know the dialog was closed, without calling the callback -> denied. From debugging it, it seems to get triggered after the callback was potentially triggered by a successful upgrade, so the notification callback can assume, if the callback is still not called, that the upgrade was denied. Do you think this could work ? – Lukas Kurz Feb 27 '22 at 12:59
  • You can use that approach, but generally in iOS you don't pepper the user with dialogs. If they deny the upgrade then you live with it. You can display a screen somewhere that lists the current authorisation and provides a button to go to settingz – Paulw11 Feb 27 '22 at 18:17

0 Answers0