Re: [web-bluetooth] GATT operation in progress - how to handle it?

I'd strongly suggest implementing the queue directly inside the UA. 
That's what CoreBluetooth does (and I think Windows as well if I'm not
 mistaken).
On Android however each app must implement the queue itself. Since 
it's undocumented (as far as I've seen) on Android that you can only 
have one outstanding GATT operation, this has resulted in very many 
stack overflow questions. Also, because the same queue must be used 
for all different operations (read/write characteristic/descriptor) 
every app must basically create their own wrappers around 
BluetoothGatt which is kind of annoying that does the enqueuing. And 
since there are quite many Android programmers that are newbies it is 
sometimes hard for them to understand how to do this correct. 
Especially that if you enqueue all write operations for example and do
 some wrapper functions for that, you also need to remember to wrap 
all read requests using the same queue as well.

Just see
http://stackoverflow.com/questions/34215880,
http://stackoverflow.com/questions/34523451,
http://stackoverflow.com/questions/36163998,
http://stackoverflow.com/questions/39638731,
http://stackoverflow.com/questions/39661417,
http://stackoverflow.com/questions/39109178,
http://stackoverflow.com/questions/30398599,
http://stackoverflow.com/questions/28493281

Of course it's easier with promises to implement a queue yourself 
rather than having a global complete event as in Android, but you 
still would have the problem that you need to wrap all kind of GATT 
operations in an additional layer.

The problem with if a user enqueues requests faster than the 
peripheral can consume is pretty small I think. Normally you send so 
small amounts of data that upper bound is not a problem and the 
problem would exist regardless if the queue implementation is in the 
UA or the js app. The js app programmer could still implement 
flow-prevention mechanisms by waiting for the promise to finish before
 issuing the next request if he is worried about sending data too 
fast.

-- 
GitHub Notification of comment by Emill
Please view or discuss this issue at 
https://github.com/WebBluetoothCG/web-bluetooth/issues/188#issuecomment-249244178
 using your GitHub account

Received on Friday, 23 September 2016 16:50:39 UTC