- From: Emill via GitHub <sysbot+gh@w3.org>
- Date: Tue, 02 Jun 2020 20:23:25 +0000
- To: public-web-bluetooth-log@w3.org
Error handling is done with the `startNotifications()` call. The promise it returns can be rejected if notifications could not be started. Note that this call results in a GATT transaction telling the remote device to enable notifications and the promise result is based on the result of this transaction. If notifications could successfully be enabled, `characteristicvaluechanged` events will be delivered when notifications arrive. There is nothing that could suddenly cancel these, unless the Bluetooth stack is buggy, so you should never have to worry about this failing. (Until disconnection when notifications stop). UNLESS some other app on the same device writes to the CCCD descriptor to disable notifications (particularly on Android where the Bluetooth stack does not manage the CCCD writing, but the app does, or in this case the Web Bluetooth implementation). Unfortunately the Bluetooth Core GATT/ATT design isn't really built with multiple apps in mind but only sees the GATT client as one single client. All major operating systems multiplex all apps as one single GATT client but a GATT response is only delivered to the app that made the request. So, at least for Android it would be impossible to detect when an other app suddenly tells the remote device to stop sending notifications. -- GitHub Notification of comment by Emill Please view or discuss this issue at https://github.com/WebBluetoothCG/web-bluetooth/issues/500#issuecomment-637785598 using your GitHub account
Received on Tuesday, 2 June 2020 20:23:28 UTC