Baseflow / Baseflow/flutter-permission-handler
[Enhancement proposal]: Split out service status checks from Permissions
- Dominant language
- Dart
- Stars
- 2.2k
- Forks
- 970
- Avg merge
- 14h 22m
- Merged PRs (30d)
- 2
Description
### Please check the following before submitting a new issue.
- [X] I have searched the [existing issues](https://github.com/baseflow/flutter-permission-handler/issues).
- [X] I have carefully [read the documentation](https://github.com/baseflow/flutter-permission-handler/blob/main/permission_handler/README.md) and verified I have added the required platform specific configuration.
### 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 https://github.com/Baseflow/flutter-permission-handler/issues/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 like `location`, `bluetooth`, `telephony` etc. There is an extension on `ServiceType` with a member `status`, which allows for checking the status without using permissions, e.g.
```dart
extension ServiceTypeActions on ServiceType {
...
Future get status => _handler.checkServiceStatus(this);
...
}
```
This allows users to just do:
```dart
await ServiceType.bluetooth.status
```
If you want to additionally keep the current way and let the user check service status based on the permissions, `PermissionWithStatus` gets a new member `service` and the extension `PermissionWithService.serviceStatus` gets updated to
```dart
extension ServicePermissionsActions on PermissionWithService {
...
Future get serviceStatus => _handler.checkServiceStatus(service); // not _checkServiceStatus(this)
...
```
or even just
```dart
extension ServicePermissionsActions on PermissionWithService {
...
Future get serviceStatus => service.status;
...
```
In the BT example, `Permissions.bluetooth`, `.bluetoothScan`, `.bluetoothConnect` etc. all are a `PermissionWithService` whose `service` member returns `ServiceType.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.
Contributor guide
Assessment
This issue has not been assessed yet.