Design a way for developers to handle devices that come into range "later" about web-bluetooth

[keybuk]

This is an interestingly similar case to reconnection

[scheib]

Reconnection issue: #31 Specify how re-connection works

[jyasskin]

@slightlyoff pointed out that we also need to define what happens if a suitable device is already available when the site requests "later" access (requestDeviceLater()?). The UI for this should probably be site-centric like requestDevice(), rather than the device-centric UI described in the first comment. If requestDeviceLater collapses into requestDevice when a device is already available, maybe they should be the same function, with just an option to turn off either behavior variant?

@keybuk It's similar to reconnection, except with reconnection the browser has a device address to reconnect to, while with requestDeviceLater, the browser only has a list of service UUIDs.

[keybuk]

Not necessarily; the browser only has a device address if the device doesn't use purely random MAC addresses

[jracle]

@keybuk is right, we need to pay attention to how we handle this scenario with context of privacy feature and pure random MAC addresses.

@jyasskin this is indeed a very interesting scenario, though I'm not a fan of 'Later' suffix. I'd prefer sth like 'defer'. We could use an option to requestDevice(). Is it similar to the autoConnect option in [BluetoothDevice.connectGatt](https://developer.android.com/reference/android/bluetooth/BluetoothDevice.html#connectGatt%28android.content.Context, boolean, android.bluetooth.BluetoothGattCallback%29)?

[reillyeon]

Discussed at the TPAC 2019 F2F:

• In the case where the page is not closed the website can use the watchAdvertisements() method to detect the service announcement.
• In the case where the page is closed we could implement the ability for the site to register for a passive scan (different than requestLEScan()) which would fire a service worker event when an advertisement is received. This has been filed as #453.