Adding expiry warnings to Medtrum Nano pump view

[vanelsberg]

Medtrum Nano pump: Alert user on patch expiry

Context:
By factory default, the Medtrum system expires a Nano Patch after 72 hours. The AndroidAPS pump driver includes an option to disable patch expiry, allowing the patch to be used beyond 72 hours.

Options were discussed to remind the user that:

1. Patch expiry is disabled
2. The patch is (about to) expiry.

This PR implements:

1. Coloring the "patch Activation/age" field when the patch age exceeds time defined in overview->status lights
2. Coloring the "patch expires" field when the patch is about to expire.
3. Show emphasize when patch expiry is “Not enabled”.

[vanelsberg]

Screenshot example:

[jbr7rr]

Use themed colors:
like:

AndroidAPS/pump/combov2/src/main/kotlin/info/nightscout/pump/combov2/ComboV2Fragment.kt

Line 121 in faa4c91

else -> rh.gac(context, app.aaps.core.ui.R.attr.defaultTextColor)

That way you can get rid of the green and it will work among all themes

See also:
#3258

[vanelsberg]

Additional remark:
I's prefer using themed colors and the ability te reset color to DefaultTextColor.

This would need adding context and assuming this would have non-trivial impact on driver implementation. So proposing to solve this first, preferably in a separate PR with proper testing?

[Philoul]

Hum,
Personally, I don't like the complete disconnect from the thresholds defined in the Overview...
Having hardcoded thresholds at 72 hours and 6 hours risks generating text of different colors depending on whether you're looking at the Overview or the Medtrum plugin, especially for those who have disabled the Patch expiry limit...
So in my mind, when Patch expiry has been disabled by the user, we should stick to thresholds defined in overview preferences by the user, and not use hardcoded values defined into Pump Driver, to get the same warning/urgent colors everywhere.

BTW It's understandable if the user decide to keep pump expiry (72h / 6h) within Medtrum driver, but define other thresholds (with longer duration) within overview preferences

• maybe we could "force" the pump thresholds within overview if durations are longer than pump configuration...

Maybe a topic to be discussed...

[vanelsberg]

TODO also: optimize code for readability/dev: function is getting too large...

[vanelsberg]

@Philoul @jbr7rr Added new commits.

1. General refactoring on code readability and maintenance
2. Added themed colors

Regarding themed colors:
ModelView sets colors but has no access to ViewFagment
For themed colors gac() needs access to the ViewFragment (which it has not)

Current commit solves by:
As both ModelView and ViewFragment have access to pump object. Pump object now holds statecolors initilized on view craetion
Modelview now gets the status colors from MedtrmPump object.

[vanelsberg]

@MilosKozak Regarding themed coloring and gac()
Medtrum pump plugin seems different from other pump plugins implementations: most of them have view context available on model object. Can't think of any other way to solve the Medtrum separation of Model's view and fragment.
How do you see this?

[swissalpine]

Is this really necessary???
I don't see any benefit and I don't like to have it.

[Philoul]

@vanelsberg , following our discussion today, I made some search on MVVM architecture, and here the wording is important...
It means: Model-View-ViewModel (so a 3 layer rocket 😉)

• Model is for "business" or "data" information management
• then ViewModel should manage the different states and the UI logic
• finally the View is only here to present information or get user actions (click on button...).

If I map this mindset within our architecture, most plugins have currently only 2 layers:

• plugin class corresponding to Model
• fragment class which includes a mix of View (presentation and Listeners) and ViewModel.

We will have to think differently if we want to go in this new architecture...

Standard flow of information for presentation is Model (plugin side for data) -> ViewModel (new layer for states) -> View (fragment to show information)

Then when user do something (click, write, select) the flow is opposite

It starts from View (Listeners, get text...) -> ViewModel (UI logic, states, interaction) -> Model (manage impact on data or business treatment) within plugin...

• if you need to use rh.gac(), then in my mind it's pure view management so this line should be within fragment (View layer)
• pump is on "business / data" area (Model layer) and should not manage any color information, so the problem should probably be managed between the flow of information between ViewModel and Fragment if I correctly understand 🤔

These explains are for me pure theoretical and I'm not skilled enough to analyze your proposal, so feel free to correct me (I'm learning here 🤓...)

[vanelsberg]

...Model-View-ViewModel (so a 3 layer rocket 😉)

Can follow you line of reasoning and mostly agree with it. Not een expert on the subject but I think current Medtrum plugin implementation uses what looks like MVC. Other plugins seem to use MVVM where the ViewModel exposes data to the View through binding?

Plugin has Model/View in line with the way I see the basics:

1. Model → View:
   View gets data from model (e.g., "What’s in row 3, column 2?").
2. View → Model:
   View signals the model to update the data.
3. Model → View (Notification):
   Model notifies the view when data changes, so the view can refresh

With MVC Model and View are strictly separated which in my opinion is the case. So, in the above (our case) Model is presenting the themed string data for updating the view. Data source in this case is the Pump object, which with my change now includes themed state color definitions because in current implementation Model cannot (gac() needs View context which is not available to the Model) . May be there is a better way (as other plugins are designed in a way where view context is available in Model through binding). But afaics this would need a redesign of the current pump plugin (?) which is not something I can do.
To me current solution is not ideal but solid enough to do the job?

[vanelsberg]

Force-pushed into one single commit

[robertrub]

What about the new FW that limits pod life to 5 days ? After 5 days, only basal is given. No alert or message seems to explain what is happening. How to treat those cases ?

[vanelsberg]

What about the new FW that limits pod life to 5 days ?
Good question! Already thought about that myself, but I think this is beyond the purpose of current PR.

Sure. Once it is clear what limits on what FW versions are active, based on this PR I can add warnings relatively easy. Pump driver itself then also needs some additions were disabling current pump expiry is overruled. Can be the subject of a separate PR. (I think @jbr7rr and others are currently looking into this?)

(Btw: I like to keep PR's as clear as possible, targeting a single goal. So, not holding of. I'd be happy to support @jbr7rr in this or taking this in a new PR)

[vanelsberg]

@jbr7rr @Philoul @robertrub @swissalpine
Any suggestions/reason(s) against merging this with dev?

[robertrub]

Built now, will test this afternoon

[vanelsberg]

Testing this PR:

• Easiest way to test themed colors are used check the "Patch expiry" field when expiry is disabled: text should color according to status lights in overview (=yellow in dark mode)
• Switch to App Color Schema to "light": colors should be accordingly, Activation field text should show (<> black)

Remark: While testing I found that updating AAPS sometimes did not forced MT driver to fully initialize. When no themed coloring, try restarting/exit AAPS.

[vanelsberg]

Is this really necessary??? I don't see any benefit and I don't like to have it.

Warning colors are according to status lights in AAPS overview? Warning for disabling expiry is in on feedback from Medtrum. This imho is also a safety concern, making sure user is knowingly extending pump from the default and recommended 3 days.

[vanelsberg]

• Updated: simplify + fix: themed colors not always set
• Force-pushed into one single commit

[vanelsberg]

PR/Commit#94e7cc57
Some code optimizations + fix on initialisation done. Now one single commit
Merges ok with current dev. Test ok (for me).

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[vanelsberg]

Feedback: removed warning triangle, color only for patch expiry field.

[swissalpine]

Everything works technically as expected. Therefore: No objections!
In terms of content, I still cannot agree with the necessity that the removal of the time limit must and should be marked as a warning (at least the exclamation mark is gone: THANK YOU!). However, I think it's good that the activation time changes color after three days.

[vanelsberg]

Have been running this PR with latest dev's for the past 4 weeks and did not find any issues.
@MilosKozak What do you think: can we merge this PR?