- 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