osaid-keymanager v3

[jwoglom]

Add osaid-keymanager with osaid-keymanager-v2 fixes, as a branch on loopandlearn/OmnipodKit (to avoid needing to fetch my fork as an additional git origin)

[marionbarker]

Status

NOTE to people not part of the private beta test who are reading these PR with interest.

• You cannot use this code to pair an O5 pod
• This version only gives you the option to control Classic (Eros) or DASH
• There are additional instructions only available to members of the private beta test
• Please let us test and analyze results
• We are working as fast as we can

Previous PR

Refer to the original version of this PR here:

• Original PR 53: version when repos were private
• Replacement PR 54: copied the PR while repos still private but needed to delete and create a new fork
• Repo was made public which broke the connection to jwoglom fork - making jwoglom public was insufficient

In the interim, some issues were reported, updated and fixed in the the jwoglom repo - which was later deleted and reforked so I can't link to the PR where the updates were reported, tested, approved and merged into the jwoglom/osaid-keymanager branch.

This comparison replicates the changes that were made recently.

• b84cbad...acb6d59

The new jwoglom repo is a new fork

• The required branch (for this PR) was pushed directly to the loopandlearn upstream repository for OmnipodKit

Previous testing

There were detailed notes here (but this was a different version of the code)

• Fetch O5 certificates from OSAID Keymanager (2) #54 (comment)

Updated testing

From memory -

• The bug where you request a cert and get one then cannot proceed to pairing with an O5 is fixed.
• Some localizations were updated.
• The Pod Certificate rows is now found just above Pod Diagnostics but only when O5 is the selected Pod type
• Some action buttons were removed that were not needed
• The Pump Manager details are updated as soon as a cert is obtained, even when no Pod is paired

[itsmojo]

This v3 version holds up better and seems better organized for typical use and for cases involving certificates coming and going in various ways in different places. Thanks for all the awesome work on this James!

The Pod Certificate label is not appropriate since it is a certificate for the controller and not the pod. How about changing this to be Certificate Details instead. This would be a similar naming convention as Pod Details and it makes more sense as the certificate isn’t changing per pod.

I believe if a user forgets the certificate used for an active O5 pod session, then after the pod is deactivated (which might occur days later), a better and more natural flow from the Pod Deactivation would be to go directly to Pod Type instead of Omnipod 5 Setup. If the certificate deletion was because the user was planning to revert back to DASH pods, they will be placed exactly at the right spot at the needed time. This is also more consistent if the user were to cancel from Deactivate Pod since they go back to the HUD and tapping “No Pod” there then goes to Pod Type and not Omnipod 5 Setup. Going directly to the Omnipod 5 Setup could also be confusing if the user forgets that they had previously deleted their certificate and it doesn’t provide an easy out if they have no Internet access or they aren’t going to continue using an O5.

We shouldn’t need to have a “Retrieve Pod Certificate” button like this and all its associated logic. There just needs to be added checks to ensure we have the needed certificate for our controllerId before going to the pairing view. If not, we can invoke either use refreshO5IdsFromCertStore() to fetch a new set of ids (if there are other available certificates) or else flow directly to the Pod Type view (if there are no other available certificates).

Tapping Forget Saved Certificate will display "Your current Omnipod 5 Pod session will not be affected, but you will be unable to pair with a new Omnipod 5 Pod until you reconnect to the Internet to download a new certificate.” or “You will be unable to pair with an Omnipod 5 Pod until you reconnect to the Internet to download a new certificate.” depending on whether there is an active pod session. But these warning messages are inappropriate when there is more than one certificate. In this case, this displayed text could be “A new certificate will be used for the next Omnipod 5 pairing.” (if the active pod’s controller matches matches the certificate being forgotten) or omitted completely (if there is no active pod or the active pod’s controller doesn’t match the certificate being forgotten).

How about simplifying this text a bit to read: “Tap ‘Continue’ to download a certificate to be stored in order to pair with Omnipod 5 Pods.”?

Currently the following screen is shown if no Internet connection is detected when tapping Continue.

While this screen is shown if the Internet connection goes away during the Omnipod 5 Setup sequence.


I think the first one has a bit more than it needs and the second one doesn’t offer any recovery suggestions. How about combining these to a single no Internet connection message like “The Internet connection appears to be offline.\n\nPlease connect to Wi-Fi or Cellular Data and try again.” that can be used for both no Internet connection cases.