Open beaufortfrancois opened 8 years ago
With the BLE APIs in general (but at least on macOS), when scanning for devices, we scan for advertisement. For having the connected devices, we have different API. I'm guessing it would be still interesting to still be able to make the difference between both result. That's why I think it would be interesting to filter for one or the other according to what we want to do. And the best example would be to make sure the user will choose the right device to upgrade the firmware.
Seems like a reasonable filter. Is there a reason to put it directly on the RequestDeviceOptions
instead of in a BluetoothRequestDeviceFilter
?
Can we implement this on all platforms? I think so, but I'll need to double-check before adding it to the spec.
Regarding the implementation, macOS has retrieveConnectedPeripheralsWithServices and Android has BluetoothManager.getConnectedDevices() and on windows we basically do this whenever someone calls StartDiscovery. So it's possible to implement on all platforms.
@jyasskin I followed acceptAllDevices
pattern. We can also add it to BluetoothRequestDeviceFilter
. Either way is fine. But we may want to be consistent.
Whatever option we choose, indeed talking about our (Logitech's) devices, they don't advertize when connected. We need to have a way for retrieving them, while also being able to listen for advertizing ones (and be able discriminate same devices from one another).
Is it possible to obtain a list of (non advertising) connected devices now?
In the current specification (and the Chrome implementation) connected devices will appear in the chooser. There is no way to filter to only connected devices.
@reillyeon Thanks, I know that HID is blocklisted, however what if a device has multiple services, eg DFU and HID. The HID is then paired via the OS. Could the WebBluetooth still find the DFU service?
After pairing the multiservice HID device, even if requestDevice has 'acceptAllDevices:true', I can't seem to find the DFU service under the find devices. However if I set the device to advertise, requestDevice can find it.
This sounds like a Chromium issue and not a spec issue at this point. Please file a bug at crbug.com/new with information about what platform you are on.
It would also be useful to have a filter to only list not connected devices. To do this, two keys with boolean values could be added to BluetoothRequestDeviceFilter
: includeConnected
and includeNotConnected
both of which default to true.
How about adding an option to
requestDevice
filters to only only show already-connected devices? @jeromelebel thinks this is a valid use case for Device Firmware Update for connected devices such as a mouse. You don't want user to be able to select a random device that is simply advertising its presence in the chooser.