[Enhancement proposal]: Split out service status checks from Permissions #1095
Labels
P3
Issues that we currently consider unimportant.
refactor
Issues marked with refactor should be considered when refactoring the plugin.
type: enhancement
New feature or request
Please check the following before submitting a new issue.
Please select affected platform(s)
All of them, the API changes for the better ;).
Proposal
Currently service checks use permissions as input, and this sometimes is strange to use.
Bluetooth on Android is a good example. Until API level 30 there was
Permissions.BLUETOOTH
, and this is also used to check if BT is enabled on the device (almost, see #773). With API level 31,Permissions.BLUETOOTH
is removed and others (.BLUETOOTH_SCAN
,.BLUETOOTH_CONNECT
etc.) are introduced instead. This means that on phones > API level 30 we will request the new permissions, but still need to use the old / legacy one for checking if BT is enabled on the device. IMHO this sounds clumsy.An idea: service checks should not use permissions; instead, a type
ServiceType
is introduces with values likelocation
,bluetooth
,telephony
etc. There is an extension onServiceType
with a memberstatus
, which allows for checking the status without using permissions, e.g.This allows users to just do:
If you want to additionally keep the current way and let the user check service status based on the permissions,
PermissionWithStatus
gets a new memberservice
and the extensionPermissionWithService.serviceStatus
gets updated toor even just
In the BT example,
Permissions.bluetooth
,.bluetoothScan
,.bluetoothConnect
etc. all are aPermissionWithService
whoseservice
member returnsServiceType.bluetooth
.Pitch
I think the code will become easier to maintain as there will be fewer conditions with OR, e.g. https://github.com/Baseflow/flutter-permission-handler/blob/permission_handler_v10.4.2/permission_handler_android/android/src/main/java/com/baseflow/permissionhandler/ServiceManager.java#L40-L42 and easier to understand, as currently permissions are used for two purposes.
I think it will be easier for end users because they would be able to check a service status without having to think about which permission they should use for the check (but they could still do it due to the facts that the extension
PermissionsWithService.serviceStatus
would be updated.). This nicely separates the concerns of checking services vs checking permissions.Finally, I think it would make the API more robust against changes like the one for Bluetooth described above, where it is currently necessary to use a legacy permissions on new phones.
The text was updated successfully, but these errors were encountered: