Remove Bluetooth.availability

[twyatt]

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)
• resetting
• unauthorized (permission)
• unknown
• unsupported (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:

• STATE_OFF
• STATE_ON
• STATE_TURNING_OFF
• STATE_TURNING_ON

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.

[twyatt]

Per #772 (comment):

Would be nice to see this come back in platform specific APIs eventually

...and despite not being in the spirit of Kable (unified API) this would be entirely possible.