- From: Jeffrey Yasskin via GitHub <sysbot+gh@w3.org>
- Date: Fri, 29 May 2015 00:36:22 +0000
- To: public-web-bluetooth-log@w3.org
(You probably mean to call `service.getCharacteristics(uuid2)`, since [`getCharacteristic()`](https://webbluetoothcg.github.io/web-bluetooth/#dom-bluetoothgattservice-getcharacteristic) returns at most 1 object, not 6.) If the developer calls `requestDevice(filter: [{services:[uuid1]}, {services:[uuid3]}])` then they need to call `getPrimaryService(uuid1)` to figure out which filter their device matched. Getting `null` back from that call isn't exceptional. There are also cases, like in the [`heart_rate`](https://developer.bluetooth.org/gatt/services/Pages/ServiceViewer.aspx?u=org.bluetooth.service.heart_rate.xml) service, where certain characteristics are optional in the Service definition. It's not exceptional to request the `body_sensor_location` characteristic and get nothing back. There are definitely other cases where the developer expects to always get a value back (`heart_rate_measurement`, for example), and the current design would produce a `TypeError: Cannot read property 'getCharacteristic' of null` if they didn't explicitly check the result. We also have the chance that the device has moved out of range, in all of these cases. I wouldn't want developers to confuse that with an optional characteristic being absent. I don't feel particularly strongly about this choice, but I suspect we should wait for developer feedback to finalize it. -- GitHub Notif of comment by jyasskin See https://github.com/WebBluetoothCG/web-bluetooth/issues/124#issuecomment-106641262
Received on Friday, 29 May 2015 00:36:24 UTC