Remove Bluetooth.availability #737
Description
The Bluetooth.availability is problematic because it provides Available or Unavailable but it is inconsistent across platforms.
This comes down to the major differences in how Android vs. Core Bluetooth (e.g. iOS) report their bluetooth radio state and bluetooth permissions.
Core Bluetooth
Core Bluetooth combines BLE supported status, radio state and permissions via CBManagerState:
poweredOff(radio state)poweredOn(radio state)resettingunauthorized(permission)unknownunsupported(supported status)
Android
Android separates BLE supported status, radio state and permissions.
BLE supported status can be checked via the existence (non-null) value for the BluetoothAdapter. Radio state is provided via BluetoothAdapter states:
Permissions are determined via the Android permissions API.
JavaScript
On JavaScript, the scanner APIs are behind a feature flag, and the requestDevice function does not require permissions request from the user. Additionally, if BLE radio is off, the device picker dialog (shown via requestDevice) will tell the user that BLE is off and needs to be turned on.
Differences
On Android, there is no way of getting real-time permission status (it is checked on-demand) while having permission on iOS comes in via the CBCentralManager delegate (a non-unsupported) state.
Requesting permission on Android is explicit, while on Apple: permission request is presented to the user on construction of CBCentralManager.
Deprecation of Bluetooth.availability
Because of the major platform differences, there is no way to provide a consistent flow of when BLE is "ready to use" (i.e. available). As such, detecting the availability of BLE is better left to the consumer.
A possible approach will be demonstrated in the SensorTag sample app.
Bluetooth.state
It was considered if Kable should/could provide a consistent "radio state" flow (via Bluetooth.state), unfortunately: the CBManagerState.unauthorized state throws a wrench in this — as it would force Kable to either ignore that state (so that Bluetooth.state can represent solely the radio state) or for it to represent both "radio state" and "BLE permissions" (which brings us back to the original "platform inconsistency" issue). Ultimately, there doesn't seem to be a way to provide an intuitive/consistent API, and it is better left to the consumer.
Bluetooth.isSupported
Detecting if "BLE is supported" would almost be possible / consistent across platforms, except Core Bluetooth (on Apple platform) shows a permission dialog when querying BLE support, with no known way to suppress the permission dialog.