-
-
Notifications
You must be signed in to change notification settings - Fork 799
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Bug]: Requesting locationAlways does not await user's response. #1152
Comments
Looks like a similar issue was previously filed around this, but marked as resolved: #1086 (=> https://github.com/Baseflow/flutter-permission-handler/pull/1089/files#r1254302197). |
Same issue. iOS 16.6.1, physical device Pubspec.yaml Podfile |
Hi @jeffscaturro-aka, @niksen75, Thank you for reporting this issue and providing detailed descriptions. I was able to reproduce the problem and did more detailed investigation. Unfortunately the issue is not really easy to solve in our current architecture where we simply await the future when requesting permissions. The reason is that iOS will not always provide a status update when requesting "Always allow" permissions. Here are the situations: User selected "Allow once" When requesting location permissions and the user initially selected "Only once", requesting User selected "When in use" and follows up with "Keep When in use" When the user selected "When in use" at the moment we initially request location permissions Apple will return the "When in use" permission. Now if the app requests location always permission the following happens:
User selected "When in use" and follows up with "Change to Allow always" Again the user initially provided "When in use" permissions and the app is requesting location always permission:
As you can see this makes it really hard (not to say impossible) to reliably await for the correct status when requesting location alway permission. This due to the fact that in several situations iOS will simply not inform us about the status when the user makes a selection. We understand that the current solution provided by the plugin is not really helpful and therefore we are planning to do a refactor of the plugin where we will provide developers with the option to listen to a stream providing permission status changes instead of enforcing developers to await the We will keep this issue open to help track the refactor process and ensure this issue will be resolved as part of the refactor process. P.S. alternative ideas are of course welcome. |
@mvanbeusekom thank you so much for the triage and in depth explanation here, it is much appreciated and gives a great understanding of the limitations we're facing. I feel most developers can understand Apple doesn't always make it easy on us, especially when factoring in user privacy and permissions (rightfully so). A workaround we had in place was simply utilizing a WidgetsBindingObserver where we were asking for this permission and listening to its lifecycle state changes (didChangeAppLifecycleState). I hope that helps some others who stumble across this issue, and of course, other ways around this would be welcomed to include on this thread! |
For anyone reading this in the future, this is the didChangeAppLifecycleState workaround that people are mentioning:
|
@Biowulf21 What is the exact workaround and what will your method |
The app goes to suspend state when the location permission pop up appears and goes to resumed state when it's closed. |
Please check the following before submitting a new issue.
Please select affected platform(s)
Steps to reproduce
await Permission.locationWhenInUse.request()
.await Permission.locationAlways.request()
.Expected results
We expect the both requests to properly await the user's response to the iOS system dialog, and returns the user's choice.
Actual results
In the above steps, the first request properly awaits the user's response to the iOS system dialog, and returns the user's choice.
The second request immediately returns a response of not granted because the user hasn't responded yet to the dialog.
Code sample
Screenshots or video
Screenshots or video demonstration
[Upload media here]
Version
10.4.3 - 11.0.0
Flutter Doctor output
Doctor output
The text was updated successfully, but these errors were encountered: