flutter-permission-handler
flutter-permission-handler copied to clipboard
Baseflow
[iOS] Request bluetooth permission on iOS by initialising `CBCentralManager`.
🏗 Enhancement Proposal
Research the possibility to request bluetooth permission on iOS by initialising CBCentralManager.
Pitch
The current implementation only supports reading the current bluetooth permission status and doesn't allow explicitly requesting bluetooth permission. The reason is that Apple doesn't provide an API to explicitly request bluetooth permission. Instead Apple will internally handle requesting permissions when developers interact with the Core Bluetooth SDK. The process is nicely explained in the article Handling iOS 13 Bluetooth Permissions by Anupam Chugh.
From an initial scan it seems that iOS will request permissions as soon as you initialise the CBCentralManager and information about permissions changes is delivered through the CBCentralManagerDelegate delegate.
It would make the permission_handler API a lot more consistent if the await Permission.bluetooth.request() method would explicitly request the user for permission.
See also issue #585 where @jlubeck suggested this approach.
Platforms affected (mark all that apply)
- [x] :iphone: iOS
- [ ] :robot: Android
After a bit of research it indeed is true what you mentioned in the enhancement proposal.
From an initial scan it seems that iOS will request permissions as soon as you initialize the
CBCentralManagerand information about permissions changes is delivered through theCBCentralManagerDelegatedelegate.
The PR is currently made and ready for review for any possible changes, the following changes has been made in the PR:
When the CBCentralManager is initialized the user will now get prompted with the request dialog asking permission for the bluetooth permission. There has been a small change in the requestPermission method since the BluetoothPermissionStrategy would not be 'alive' long enough (removed from the memory) so the dialog would never pop-up.
The requestPermission method will now check if the permission is granted (status != PermissionStatus.denied). If that's the case the completionHandler gets called and the BluetoothPermissionStrategy will be removed from the memory. However, if the status is denied, the completionHandler and the requestedPermission will be saved in a variable and the completionHandler will not be called, keeping the instance of the BluetoothPermissionStrategy 'alive'.
After this, the user will get the dialog to either allow or deny the permission. After the user made a choice, the centralManagerDidUpdateState gets called automatically since it's a delegate. In this method the variables for the requestedPermission and completionHandler are used to see what the users option was (allow/deny) by checking the PermissionStatus of the requestedPermission, and after that the completionHandler will be called with the status of the requestedPermission, resulting in removing the BluetoothPermissionStrategy from the memory after handling the permission and updating the status.
sorry, so this bluetooth is a problem solved in the latest version 8.1.6?
sorry, so this bluetooth is a problem solved in the latest version 8.1.6?
There are some small issues about the PR that I made that needs to be resolved before the new version gets published. Currently I don't have the access to an Apple device so I can change the PR. I will update you @mcorbelli when the PR is approved!
