Skip to content

Specify a Bluetooth Scanning API. #239

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Merged
merged 6 commits into from
Aug 2, 2016
Merged

Specify a Bluetooth Scanning API. #239

merged 6 commits into from
Aug 2, 2016

Conversation

jyasskin
Copy link
Member

@jyasskin jyasskin commented May 9, 2016

This was referenced May 9, 2016
Closed
Closed
jyasskin
jyasskin reviewed May 10, 2016
View reviewed changes
scanning.bs Outdated
</p>
<ol>
<li>
If |event| doesn't <a for="BluetoothLEScanFilter">match</a>
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note that this leaves no way to do a completely open scan. It has to be filtered for some UUID or Manufacturer ID. Is that OK, or do we need an extra filter type to match everything? (I don't want to make no-filters the sign for completely-open because that makes the API non-monotonic: reducing the number of filters would match less, less, less, and then more advertisements.)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Similar to #234 I think developers will have good use cases for matching everything.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is BluetoothLEScanOptions.acceptAllAdvertisements now.

@beaufortfrancois
Copy link
Member

I wonder why developers would use requestDevice rather than requestLEScan. The latter seems more powerful and better in terms of UX. Could you comment on the drawbacks?

@jyasskin
Copy link
Member Author

@beaufortfrancois At the moment, requestLEScan gets you a bunch of BluetoothDevice objects, but all of their .gatt fields are null (unless you already had permission to communicate with them), so you have to use requestDevice to communicate. I think it's worthwhile to give folks a way to upgrade, but we need to ask the security UI folks what it should look like, and it'll probably be designed to push people toward just using requestDevice() if they don't really need to control the scan.

@beaufortfrancois
Copy link
Member

beaufortfrancois commented May 13, 2016 •
edited
Loading

This makes more sense now ;)
Thank you @jyasskin!

So once you have a BluetoothDevice object, the way to know if you have to use requestDevice is to check device.gatt... but how do you make sure that only this device will be shown in the bluetooth chooser?

navigator.bluetooth.requestLEScan({
  filters: [{manufacturerData: 0x004C}]
}).then(() => {
  navigator.bluetooth.addEventListener('advertisementreceived', event => {
    if (!event.device.gatt) {
      // How do I connect to this device specifically?
    }
  })
})

@jyasskin
Copy link
Member Author

There's no API for that yet, and I've mailed the security UI folks to ask their opinion on it. The benefits of the chooser are that 1) the user has to pay enough attention to make a choice, and 2) the user can override the page's idea of which device is best. If we ensure that exactly one device appears in the chooser that opens as a result of an advertisement, then we lose both of those. On the other hand, we might be able to add a hint field to RequestDeviceOptions, which could ensure that the preferred device is listed first if it matches the other filters.