W3C home > Mailing lists > Public > public-web-bluetooth-log@w3.org > August 2016

Re: [web-bluetooth] Don't fire characteristicvaluechanged for Read Responses

From: Emill via GitHub <sysbot+gh@w3.org>
Date: Tue, 16 Aug 2016 15:56:01 +0000
To: public-web-bluetooth-log@w3.org
Message-ID: <issue_comment.created-240147479-1471362959-sysbot+gh@w3.org>
> I don't think we would be able to implement this given that macOS 
follows pretty much the same pattern. 
https://developer.apple.com/reference/corebluetooth/cbperipheraldelegate/1518708-peripheral?language=objc

Yeah it sucks that Apple did it this way. We have reported this to 
them as well but they really didn't seem to care. It would be bad to 
be forced to make it worse for the other platforms that Web Bluetooth 
run on just because Apple has made this very strange decision.

I really think this pattern is very odd. You expect to get the read 
response as a response to a request, not as some event. Event 
listeners are usually for something that can be triggered any time. 
Read responses are not triggered any time, they are only triggered as 
a response to read requests.

How do you anyway implement, on top of CoreBluetooth, at 
https://webbluetoothcg.github.io/web-bluetooth/#dom-bluetoothremotegattcharacteristic-readvalue,
 the step "Resolve promise with this.value."? If a notification 
arrives before the read response, do you then incorrectly resolve the 
promise with the notification value, rather than the read response 
value that will come in later?

Until Apple decides to fix their API, one could use a workaround that,
 after a read request is issued, assume the first 
`didUpdateValueForCharacteristic` that comes in is the response to the
 read request. Further `didUpdateValueForCharacteristic` are assumed 
to be notifications. For all other platforms such as Android, Windows,
 Linux no workarounds would be needed since they have done it the 
"correct way".

> I don't think this was meant to imply that the actual value has 
changed but rather that we updated our copy of the value. Maybe 
`characteristicvalueupdated` would be more appropriate.

If the event is only triggered due to notifications/indications I 
think both names work. If it handles both notifications/indications 
and read responses, `characteristicvalueupdated` would be more 
appropriate.

-- 
GitHub Notification of comment by Emill
Please view or discuss this issue at 
https://github.com/WebBluetoothCG/web-bluetooth/issues/274#issuecomment-240147479
 using your GitHub account
Received on Tuesday, 16 August 2016 15:56:08 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 16 August 2016 15:56:08 UTC