Baseflow / Baseflow/flutter-permission-handler

[Enhancement proposal]: Split out service status checks from Permissions

Open
#1,095 0 comments 0 reactions 0 assignees View on GitHub
P3 refactor type: enhancement
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

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.