connect to device directly if it was a disconnect with existing device

[mdmohsin7]

• Initially device was not reconnecting compared to 427 because the locator was not being stored in prefs (in btdevice model) and the new transport connection relies on locator to know what type of transporter to use
• Clear images from mem cache when the app is being minimised (uses less mem when the app is in bg which would allow it to run for longer before os kills it if there's too much mem usage). When I had many apps in bg, with this change the app stayed active for longer before the os killed it
• Set restoreState to true so the OS can restore conn if the app gets killed in bg (if you restart the phn then the device will reconnect automatically or if the app gets killed by os, it might get relaunched in bg after there's enough available memory)
• Use device id from prefs if the _devices list in the device service ever gets cleared or become empty instead of falling back to discovering devices (because scanning in bg is costly and limited). In worst case we any will scan for devices

[beastoin]

1/ https://github.com/BasedHardware/omi/pull/3110/files#diff-c887ba3d8e70bca5b4d97dea1232849b8d79206eee68544d4752e9292c8f7224R181-R198

why do we need this step but not let the discovery auto connect to the desirable device?

2/ https://github.com/BasedHardware/omi/pull/3110/files#diff-889c5af0cffe6339ab8a6ec11ff801b4ec7c400eef7760d2dd2be8b54aa5a3ecR135-R148

discovery will scan for the devices nearby; that's the source of truth to let us know which device is ready to connect. why do we need to add the device that's not in range?

@mdmohsin7

[mdmohsin7]

1/ Scanning for devices in the background is resource-intensive on iOS, and the operating system itself tries to limit excessive scanning. Since the device ID remains the same, we first attempt to connect directly to check if the device is available. If the device is available, the connection succeeds; if not, we then proceed to scan for it.

2/ We also store the most recently connected device in preferences. If a disconnect occurs and the device list is empty, we fall back to connecting with the device stored in preferences. This works because that was the last connected device, and if it’s still in range, the connection will succeed. If not, the attempt will fail. The device list can be empty because iOS may delay or batch scan operations in the background, as mentioned in Apple’s documentation. Scanning in the background is not the same as scanning in the foreground.

In both cases (1 and 2), we take an optimistic approach by attempting to connect first, hoping the device is available. This reduces the need for unnecessary scans.

From Apple’s documentation:

Although you can perform many Bluetooth-related tasks while your app is in the background, keep in mind that scanning for peripherals while your app is in the background operates differently than when your app is in the foreground. In particular, when your app is scanning for devices in the background:

The CBCentralManagerScanOptionAllowDuplicatesKey option is ignored, and multiple discoveries of an advertising peripheral are coalesced into a single discovery event.

If all apps scanning for peripherals are in the background, the interval at which your central device scans for advertising packets increases. As a result, it may take longer to discover an advertising peripheral.

These changes help minimize radio usage and improve battery life on iOS devices.

I might be missing some edge case or confusing something here, so pls lmk if any part of this reasoning is off sir
@beastoin

[beastoin]

nice, lgmt @mdmohsin7, please go ahead.