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 provided 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.

isSupported

Detecting if BLE is supported can be made uniform/consistent across platforms, and will be provided.

[twyatt]

UPDATE: Even providing isSupported has proven challenging (due to Apple limitations with being able to query and always showing the user an intrusive permission dialog). Providing isSupported in Kable is still being considered.