Eventual BG with 1 decimal in the app and in the watch app

[bjornoleh]

• Use targetFormatter instead of numberFormater for eventualBG in the app, since this has the appropriate maximumFractionDigits = 1

• Change eventualFormatter to use maximumFractionDigits = 1 instead of 2 on the watch

Resolves #319

[bjornoleh]

Eventual BG as presented with this patch:

52,8 mmol/L to the left, 951 mg/dL to the right (random numbers from sim phone/watch/CGM and pump)

[mountrcg]

@bjornoleh there is a glucoseformatter also in ./FreeAPS/Sources/Modules/Home/View/Header/CurrentGlucoseView.swift which should fit perfectly for this issue

[bjornoleh]

CurrentGlucoseView

Thanks for looking! That is in another file, right? I don't think that glucoseFormatter will be accessible here. But I suppose my solution is a minimal and acceptable change, isn't it?

[mountrcg]

But I suppose my solution is a minimal and acceptable change, isn't it?

Totally!

As per discussion of targets and rounding errors leading to changed targets after multiple unit switches, I suspect that using

Trio/FreeAPS/Sources/Modules/Home/View/Header/CurrentGlucoseView.swift

Line 13 in 20ba334

private var glucoseFormatter: NumberFormatter {

would not lead to these. I think @polscm32 already centralized all formatters in Helpers at one point in some branch, which I guess is something we should also do. It only popped into my mind when viewing this PR as there are some inconsistencies in how rT.variables are handed over from oref to swift. Some are "convert_bg functioned" some always in md/dL - I think I am partly responsible for that and started fixing it, so I stumbled across glucoseformatter just this week.

[bjornoleh]

@mountrcg , perhaps you can write up an issue about this for later?

[Sjoerd-Bo3]

LGTM and tested on watch

The base branch was changed.

[AndreasStokholm]

Looks good and tested in sim with iOS 16.4, iOS 17.5, watchOS 10.4