Skip to content

Conversation

@bharat
Copy link

@bharat bharat commented Feb 12, 2017

Updates

3/21/2017

  1. added new screenshots
  2. working on new to-do items at the bottom of this description.

3/23/2017

  1. added higher res screenshots

Details

This is the basic framework for exposing the glucose history and the predicted glucose in the widget. This takes advantage of the widget display modes that lets you zoom open the widget and show more details.

compact form looks like normal, but note that there's a [show more] link in the top right:
screen shot 2017-03-23 at 7 39 56 am

expanded form looks like this:
screen shot 2017-03-23 at 7 40 06 am

Work completed:

  • show the target BG range
  • move the chart code into the LoopUI framework
  • update screenshot to show latest layout
  • tighten up prediction values to be start date, interval and array of doubles.
  • reduce historical glucose data to 30 minutes so that we have a consistent experience regardless of whether the last data update came in when the device was locked or unlocked
  • Don't store new property in StatusChartsManager extensions - use a protocol or delegate in the common class and inject appropriate object from view controllers in Loop and extension
  • only serialize the most recent SensorDisplayableContext since that's the only thing we show in the extension UI
  • don't hardcode chart end date in the widget, use the last prediction value -- punt this for now
  • get rid of eventual glucose and use the last prediction value

@elnjensen
Copy link
Contributor

Looks great! What sets the amount of time displayed on the x axis?

If the show more / show less is toggled once, will it stay that way next time you display? Or will you have to open it each time? The former seems preferable to me if it's possible.

Also, I'll put in another plug for displaying IOB ("Active insulin") in the status widget if possible. Separate issue, I know, but it would be useful to see it there.

@ps2
Copy link
Collaborator

ps2 commented Feb 26, 2017

@bharat Let me know when you think this is ready for review.

@bharat
Copy link
Author

bharat commented Feb 26, 2017

It's worth a review just to make sure I'm headed in the right direction - but I haven't had much time to dig into this recently so I haven't advanced the ball beyond the initial commit...

@bharat
Copy link
Author

bharat commented Mar 13, 2017

ok. I've cleaned up most of the major issues and synced this up with the latest changes in dev. We're down to two extension unsafe dylib warnings, and I still need to work on the BG range code - but it's headed in the right direction. As far as I can tell. Feel free to lob in criticism!

@elnjensen
Copy link
Contributor

Following this with interest - let me know if you need any testing of anything. Thanks for your work on this.

Bharat Mediratta added 2 commits March 20, 2017 21:19
SwiftCharts in my own fork. The master branch doesn't compile and I want
to make the smallest possible change to bring this in line.
@bharat
Copy link
Author

bharat commented Mar 21, 2017

ok - this is now functionally complete and doesn't generate any warnings.. yay! I need to do a pass over it just to make sure there isn't anything dumb in there and then it'll be ready for a real review.

Bharat Mediratta added 8 commits March 21, 2017 12:00
Now it's a start date, an interval, and a series of double values.
Add a TargetPointsCalculator to StatusChartsManager which Loop and
Loop Status Extension can each implement separately.
Also, fix a bug where target ranges should get completely recalculated
when you delete one of them.
@bharat
Copy link
Author

bharat commented Mar 23, 2017

@ps2 - not sure why the Travis builds are failing. I can't repro the failure in my dev environment and I don't see clues in the Travis output. :-/

@sarahspins
Copy link
Contributor

I know it's been requested before, but any chance to add a tiny IOB chart as well?

@bharat
Copy link
Author

bharat commented Mar 23, 2017

@sarahspins that's a good idea (and I know that others want it as well). would you please file a separate feature request for that? I'd like to do it separately since I'm trying to avoid growing the scope of this pull request.

@sarahspins
Copy link
Contributor

Will do :)

@bharat
Copy link
Author

bharat commented Mar 27, 2017

@ps2 - I think this is good to go!

@ps2 ps2 merged commit 1885f09 into LoopKit:dev Mar 29, 2017
ps2 added a commit that referenced this pull request Apr 7, 2017
* refactor of CGM device management

* Adding missing files from last cgm refactor pr

* Fail if any command in pipeline fails

* handling a memory warning and tweaks to the diagnostic report

* Fix tests that had been breaking for a while but were hidden by xcpretty swallowing exit code

* Show the glucose chart in the widget (#377)

Show the glucose chart in the widget. Thanks @bharat!

* Swift 3.1 - rebuild all frameworks, clean up all swift warnings (#421)

* Rebuild all frameworks with swift 3.1

* Resolve all Swift 3.1 warnings

* Swift 3.1 - update LoopKit to 1.2.1 (#423)

update LoopKit to 1.2.1

* Swift 3.1 - post widget merge cleanups (#424)

* Extend ChartColorPalette in Loop target to add a .default() palette

* Update chart appropriately when we remove glucose targets

* Drop the first predicted glucose entry. It's the current glucose and its interval to the second is not uniform with the interval for the rest

* Use predictedGlucose.startIndex for clarity instead of hardcoding indexes

* Swift 3.1 - update dexcom-share-client-swift and G4ShareSpy frameworks (#422)

update dexcom-share-client-swift and G4ShareSpy frameworks

* Project and margin cleanups (#427)

* support share-only cgm source (#426)

* fall back to getting cgm data from share if no others are configured

* use absence of g5 transmitter to indicate share-only setup.

* Widget should always display data using the preferred dispay unit, (#434)

regardless of the units used in the StatusExtensionContext.

* Break the tie between two visual constraints. (#439)

"<NSLayoutConstraint:0x600000097430 LoopUI.ChartContentView:0x7f808c50aae0.height >= 100   (active)>",
"<NSLayoutConstraint:0x60000009c2f0 'UISV-hiding' LoopUI.ChartContentView:0x7f808c50aae0.height == 0   (active)>"

Lower the priority of the height >= 100 constraint.

* bump version (#441)
ps2 pushed a commit that referenced this pull request Mar 26, 2021
* using lifecycle progress state dimmed to color bar

* using lifecycle progress state dimmed to color bar
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants