Status widget - "eventually" text has more precision than the app in mg/dL

[bharat]

The app says:
"Eventually 98 mg/dL"

The extension says:
"Eventually 97.6 mg/dL"

which is right? I'm assuming the app is. Either way, consistency is good here.

[bharat]

I can no longer reproduce this issue. I believe it was fixed in 5838f6d

[bharat]

I reproduced the issue. Here's what's happening.

In the Loop App the eventual glucose description string is set by:

1. taking the last point in the predicted glucose array
2. using the ChartAxisValueDoubleUnit description function to turn it into a string which relies on
3. ChartAxisValueDouble using the integerFormatter defined in StatusChartManager

So the result appears to always be an integer. This in and of itself is likely a bug in the experience for mmol/L users who would want to see one decimal place.

In the Loop Status Extension, the eventual glucose description is set by:

1. taking the preferred unit from the context
2. using NumberFormatter.glucoseFormatter, called here and defined here

... this formatter does not define a maximum number of fraction digits.

My sense is that the way that the Loop Status Extension is doing it is more correct in general, since relying on the status chart's internal representation to calculate the "eventual glucose" value seems inappropriate.

I think the right approach is probably to:

1. Add a preferredMaximumFractionDigits to the LoopKit/HKUnit extension
2. Use the min and max fraction digits in the Loop/NSNumberFormatter extension
3. use NumberFormatter.glucoseFormatter(for: <preferred unit>) in both places

Thoughts?

[apabari]

Has this one been addressed? I haven't tried to reproduce it as of yet. Just seeking to understand if this issue should be marked as closed or not.

Thanks!

[Kdisimone]

addressed and closed