Skip to content

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

Closed

Description

@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.

Activity

  1. bharat commented on Dec 23, 2016

    @bharat
    Author

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

  2. bharat commented on Dec 29, 2016

    @bharat
    Author

    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?

  3. reopened this on Dec 29, 2016
  4. apabari commented on Jul 10, 2018

    @apabari
    Contributor

    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!

  5. Kdisimone commented on Oct 18, 2018

    @Kdisimone
    Collaborator

    addressed and closed

  6. added a commit that references this issue on Nov 16, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions