0

RxBleClient#scanBleDevices emits a sequence of ScanResult objects. In turn, ScanResult#getBleDevice provides the RxBleDevice instance from one of these emitted item.

Are there any issues with caching a RxBleDevice instance to avoid having to perform future scans?

A couple of potential use cases:

  • A scan is performed well ahead of the need to actually connect to the device.
  • A general scan is performed for an unrelated operation, so it would be efficient to utilize any other devices emitted during this scan.
Steve Yohanan
  • 757
  • 5
  • 17

1 Answers1

1

There are at least two options:

  • You can cache RxBleDevice instance yourself, as long as you keep the client instance. It internally keeps some references to objects scoped with the lifecycle of the client.
  • You can use RxBleClient#getBleDevice passing the MAC address. RxBleDevice instances are cached across the client and you shouldn't expect performance issues with creating the device.
Community
  • 1
  • 1
pawel.urban
  • 1,031
  • 8
  • 10
  • It is worth noting that some implementations of the BLE stack (i.e. Samsung's) do not connect successfuly to a device created before the `BluetoothAdapter` was turned on. In other words-after the bluetooth is turned on one must first re-scan the device before the connection will be established (even if the device was successfuly scanned before the adapter was turned off). If it won't happen `status=133` is usually returned in `BluetoothGattCallback.onConnectionStateChange()`. – Dariusz Seweryn Oct 31 '17 at 20:56
  • thanks for the reply @pawel.urban. actually, we already are caching the MAC address once we have found the device in a scan, so we can continue our existing approach to use `RxBleClient#getDevice(MACAddr)`. great to know we'll get the same benefits as if we cached the `RxBleDevice`. – Steve Yohanan Nov 01 '17 at 14:09
  • interesting information @DariuszSeweryn. we had been seeing some odd behavior with inability to connect to devices after they have been previously found. i hadn't been able to find the root cause. perhaps this is a result of the of what you describe. i am going to investigate invalidating our MAC Addr cache whenever bluetooth changes state. – Steve Yohanan Nov 01 '17 at 14:14