[itsmojo]

Background

The original Pod Keep Alive implementation was an adaptation of code from the LoopFollow app intended as a temporary bandaid measure for the Atlas pods when used with iPhone 16s and 17e'e that can have significant BLE reconnect delay times resulting in long periods of pod communication losses. Unforunately no iOS/iPhone or Insulet solutions for this reconnect problems between these devices has happened and no better software workarounds have been found in over a year. Now that that PKA is part of the unified OmnipodKit pump manager, it is due for some long overdue updates and a more viable long term implementation.

Some issues of the original PKA implmementation include:

• It uses private Storage() & StorageValue() classes for remembering its persistent state which is inconsistent with the rest of OmnipodKit.
• The PKA state is not visible in either the Pump Manager Details or Loop Reports (since it's not part of the state being held in OmniPumpManagerState).
• When Switch pump type is used to switch to a different pump type, OmnipodKit will still be held in memory.
• When Switch pump type is used to switch to a different pump type after the DASH pod type has been selected, RileyLinkBLEKit will also still be held in memory.
• If the RileyLink PKA type is selected and a RileyLink is connected, then no RileyLinks will be available when switching the pump manager from All Omnipod Types (OmnipodKit) to Minimed (MinimedKit). This will also occur if the PKA type has been changed back to Disabled before switching pump types.
• The PodKeepAliveView.swift source file contains far more than just View controller code as it was a dumping ground for all the data types and functions needed for the bandaid LoopFollow based PKA implementation.
• The current PKA view no longer correctly describes the app behavior when PKA is disabled with the newer BLE connection method being now deployed in OmnipodKit for both BLE Omnipod pod types.

New Implementation

This new PKA implementation is completely revamped and fixes all of the above listed issues. The uses of Storage()/StrorageValue() classes for remembering persistent state have been eliminated and replaced by a single PodKeepAlive value kept in OmniPumpManageState which is managed just like any other pump manager state. The various logical pieces have been split into multiple source files that make more sense. While this new PKA implementation doesn't (currently at least) support a RileyLink option to do BLE based wakeups for PKA, it does provide a framework for doing this in a way that would integrate better with OmnipodKit which already has its own RileyLink mechanisms included for use with older Eros pods.

Other highlights of the new PKA implementation include:

• When switching to another pump manager, there will be no more held references to either OmnipodKit or RileyLinkBLEKit.
• RileyLinks will no longer be mysteriously unavailable when switching pump managers from All Omnipod Types (OmnipodKit) to Minimed (MinimedKit).
• A new method for selectively enabling callbacks on pod responses that is only enabled when a timer based PKA option has been selected.
• Updated descriptions that properly explain the differences between the various PKA options for both older and newer BLE connection paradigms.
• Removes all non-View data types and functions from the PodKeepAliveView.swift source file.
• The new cleaner PKA View displays descriptions of all available options with a push button selection without having to switch between the various available options using a pull down menu to see the option descriptions.
• The new simplified implementation removes a net of about 900 lines of code even with the addition of new file headers for the various new source files that replaced the single monolithic PodKeepAliveView.swift source file.
• Fixes an additional minor and unrelated issue for a possibly delayed Omnipod View update when a Silence Pod End time has been reached.

Testing Notes

To verify that OmnipodKit and RileyLinkBLEKit are no longer being held in memory, it is necessary to run Loop under Xcode. After switching out from the OmnipodKit pump manager to the main page showing Add Pump, tap on the Xcode Debug Memory Graph icon (3 connected dots pointing to the right) in the diagnostic visual debugger section of the debug bar. In the older PKA implemenation, there will be several held references for OmnipodKit. If an Omnipod DASH pod type was selected before switching out, there will be even more held references to OmnipodKit and there will be at least one held reference to RileyLinkBLEKit. With this updated PKA implementation, there should be no held references to either OmnipodKit or RileyLinkBLEKit after switching out from the OmnipodKit (All Omnipod Types) pump manager no matter which pod type or PKA option is selected as should be expected.

The Silent Tune option now plays the silent.wav file found in the OmnipodKit/Resources directory which is a copy of the still included blank.wav file in the same directory. For testing purposes, the silent.wav file can be easily overwritten by the contents of the heartbeat.wav file for a heartbeat sound that can be heard with Silent Tune PKA option is selected and the app is not in the foreground. The app can be easily restored to its default non-test configuration by coping the blank.wav file back to silent.wav.

Other issues cited for the poor code layout and incorrect descriptions can be verified by examination of the old vs new implementations in the source code and by examination of the screen views.

Possible Future Work

With the unified Omnipod pump manager that includes all supported Omnipod pod types, RileyLinkBLEKit is always linked with OmnipodKit. If a RileyLink PKA option is eventually re-implemented for OmnipodKit, it should use the existing RileyLinkBLEKit code that is already included for the Eros pod type instead of using any code from the orignal PKA implementation which has a conflicting and overly messy standalone BLE and RileyLink implementation that was originally adapted from LoopFollow.

[itsmojo]

The Future is Now!

The latest commit does implement a RileyLink option for Pod Keep Alive which cleanly works with OmnipodKit by leveraging various parts of RileyLink support already in OmniPumpManager and RileyLinkBLEKit to support Omnipod Classic pods.

The control of the RL used for this new option is done in the Omnipod DASH (pump view). The available RileyLink devices will appear immediately under the Pod Keep Alive selection only when the RileyLink option is the selected.

Multiple RileyLinks can be used for the Pod Keep Alive RileyLink option and they will be managed just as they would be for Omnipod Classic pods. Individual RileyLink device choices under the Pod Keep Alive RileyLink option can come and go from the list of available RileyLinks device for Pod Keep Alive. The Pump Manager Details output shows the traditional Omnipod Pump Manager state that holds the necessary persistent information needed to maintain the RileyLink connection state across restarts for both Omnipod Classic pods and for the Pod Keep Alive RileyLink option at the end of the OmniPumpManagerState display.

[itsmojo]

Also removed two AI generated .md files that were left at the top level.

[ps2]

Code-wise, LGTM