Classes

VLDBluetoothPassiveManager manages reading Bluetooth peripherals passively without explicit user interaction. Passive read occurs if the application is in the foreground or background. If the application is no longer in the background but has been terminated by iOS, the application will be started if one of the peripherals being passively read is discovered. Apps using the passive manager function must have been started at least once since the phone booted.

There are situations where passive Bluetooth reading is stopped and requires the app to be relaunched. These situations include:

• When the user explicitly kills the app by swiping up on the app switcher view, the app will not be restarted by iOS when a peripheral is discovered.
• If the iOS device is rebooted, state restoration is no longer in effect and iOS will not automatically restart the app when a peripheral is discovered. The app needs to be run at least once after reboot. When the app is launched the passive manager remembers what peripherals if any where being passively read and restarts the capability.

Passive Bluetooth reading has some additional considerations due to the behavior of the iOS Bluetooth stack and background support.

• When scanning for peripherals in the background, iOS reduces the frequency and duration of the time the phone listens for devices. This may cause some peripherals to not be discovered in the background. This varies by phone model and peripheral. Generally older phone models are more likely to miss discovery of a peripheral.
• Nonim pulse oximeter, ChoiceMMed pulseOx and ChoiceMMed scale are not usually detectable when in the background.
• The Pyle thermometer is sometimes not discovered on older phone models when in the background.
• iOS has additional heuristics to determine scanning frequency which may not be documented. If multiple apps on the phone are performing background scanning, scanning may become more infrequent.
• To prevent repeated attempted reads from a device for one actual reading, the passive manager waits after a successful read until the device stops broadcasting, then waits an additional few seconds before acknowledging the device again. If attempting multiple readings in quick succession, the second reading may not be read. Instead the user should wait until the device powers off and then wait an additional 15 seconds or longer before attempting another reading.

The VLDBluetoothPeripheral class represents Bluetooth peripheral models that can be discovered or read from by VLDBluetoothPeripheralController.

VLDBluetoothPeripheralController is the primary interface for detecting and reading from Bluetooth peripherals. All peripheral updates are given to the peripheral controller’s delegate object (VLDBluetoothPeripheralControllerDelegate).

The peripheral controller only performs one operation at a time. Any current operations must finish or be cancelled before a new operation can be started. The two possible operations are pairPeripheral: and readFromPeripheral:.

If the VLDBluetoothPeripheral has requiresPairing set to true, then you must first call pairPeripheral: to ensure that we are able to communicate with the peripheral and to do any necessary pairing. When you call pairPeripheral:, you should then present to the user the instructions of the VLDBluetoothPeripheral. When the bluetoothPeripheralController:didPairPeripheral: callback is called, you can assume all pairing has been done and it is now safe to call readFromPeripheral:.

To get a reading from a peripheral, call readFromPeripheral: and pass in the VLDBluetoothPeripheral object that you want to take a reading from. The reading operation will have multiple callbacks at different stages that are reported to the VLDBluetoothPeripheralControllerDelegate. When the VLDRecord object is returned via callback, it is also simultaneously uploaded to Validic. Do not submit these records to Validic as they have already been submitted.