You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
CoreBluetooth provides support to retrieveConnectedPeripherals(withServices:). This returns a set of devices that are already connected to the device via different centrals.
We might need to check if that is a method CoreBluetooth should consider calling when scanning for a set of service ids. E.g., there might be peripherals connected the device via different applications that don't send bluetooth advertisements if their are already connected. This is where the above-linked method from CoreBluetooth comes in handy.
Solution
A solution would be to retrieve the list of connected devices upon scanning for nearby services. The biggest problem here is that we won't be able to reconstruct the AdvertisementData of a device. We would be missing their advertisedService and wouldn't be able to match it to a DeviceConfiguration (e.g., we have a similar problem in #16 where we would need a 2-step discovery step). Further, advertised information like he localName wouldn't be available and we might have unexpected naming if a device is retrieved via this route.
Additional context
No response
Code of Conduct
I agree to follow this project's Code of Conduct and Contributing Guidelines
The text was updated successfully, but these errors were encountered:
Problem
CoreBluetooth provides support to
retrieveConnectedPeripherals(withServices:)
. This returns a set of devices that are already connected to the device via different centrals.We might need to check if that is a method CoreBluetooth should consider calling when scanning for a set of service ids. E.g., there might be peripherals connected the device via different applications that don't send bluetooth advertisements if their are already connected. This is where the above-linked method from CoreBluetooth comes in handy.
Solution
A solution would be to retrieve the list of connected devices upon scanning for nearby services. The biggest problem here is that we won't be able to reconstruct the
AdvertisementData
of a device. We would be missing theiradvertisedService
and wouldn't be able to match it to a DeviceConfiguration (e.g., we have a similar problem in #16 where we would need a 2-step discovery step). Further, advertised information like helocalName
wouldn't be available and we might have unexpected naming if a device is retrieved via this route.Additional context
No response
Code of Conduct
The text was updated successfully, but these errors were encountered: