Trend arrows and time and background in complications / widgets

[poml88]

I saw from #215 that trend arrows were implemented at some point. What happened to the trend arrows? Was this dumped?

It is, of course, very useful to show the time in the complication when it was updated. I know from iOS widgets, that it is possible to have a running minute:second timer in a widget, that is counting every second, without the widget being updated. Means, that instead of the time, there could be an increasing timer in the widget showing how many minutes:seconds ago it was updated. Would that make people's life easier? No need to calculate the time difference.

Also, it is possible in some apps to have a widget with a blurred background, which makes the values easier to read in case you have for example a photo as screen background. Could that be implemented?

[dhermanns]

Trend arrows are right now dumped in favor of more background updates, yes.

I don't think that active timers or the like are possible for custom complications. Do you have code examples for that?

[poml88]

Hi, ok, that is interesting. What is the connection between trend arrows and more background updates? The arrow plus the value, it is the same update, isn't it?

I will look for code. But since nightguard also has phone widgets, it could be implemented there...

[dhermanns]

I'm using the entries endpoint from nightscout to do the background updates.

And this endpoint doesn't provide the trend arrows.

Code for the widgets would help, too. Yes.

[poml88]

Oh, I see thanks. I do not know the code in such detail. However, I would like to mention, that the trend arrow is about the most useful thing the CGMs have to offer. THE FSL3 one is really good. It is a pity we are missing out on them. But in principle the background updates are an Apple algorithm, so it should not change whereever the data is taken from?

[dhermanns]

It measures the compute time consumed. So you should return as soon as possible and do as little as possible network traffic.

I believe the newer nightscout api V3 has an endpoint that provides the state plus multiple bg entries. Maybe this is the way to go. But quite some effort to switch to it.

Phil @.***> schrieb am Mi. 10. Jan. 2024 um 16:43:

Oh, I see thanks. I do not know the code in such detail. However, I would like to mention, that the trend arrow is about the most useful thing the CGMs have to offer. THE FSL3 one is really good. It is a pity we are missing out on them. But in principle the background updates are an Apple algorithm, so it should not change whereever the data is taken from?

— Reply to this email directly, view it on GitHub https://github.com/nightscout/nightguard/issues/277#issuecomment-1885104352, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAYPBFLDLTR7BNQ7QGHNXVLYN2ZKTAVCNFSM6AAAAABBUX4JLSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQOBVGEYDIMZVGI . You are receiving this because you commented.Message ID: @.***>

[poml88]

Ok, so the less battery you use the more updates you get.

could you point me to the line of code where you do the updates, pls?

[dhermanns]

Its in the TimelineProvider

[dhermanns]

V3.9.1 is out on the Appstore now.

[poml88]

Thanks, 3.9.1 is working great on my watch. But I still would like to provide some code samples for trend arrows, timers, and blurred background...

[poml88]

Ok, actually for a lock screen widget a timer is very simple, just add this:

Text(Date(), style: .timer)
                         .font(.system(size: 20, weight: .heavy))
                         .foregroundColor(color.1)
                         .multilineTextAlignment(.center)
                         .monospacedDigit()
                         .padding(4)

Edit: Or with .relative or .offset, we have to see.

[poml88]

Hm... and for the arrow, in the TimeLineProvider, there is a bgdeltaArrow? But it is not read?

private func convertToTimelineEntry(_ data: NightscoutData, _ bgValues: [BgEntry], _ errorMessage: String) -> NightscoutDataEntry {

        return NightscoutDataEntry(
            date: Date(timeIntervalSince1970: data.time.doubleValue / 1000),
            sgv: UnitsConverter.mgdlToDisplayUnits(data.sgv),
            sgvColor: UIColorChanger.getBgColor(data.sgv),
            bgdeltaString: UnitsConverter.mgdlToDisplayUnitsWithSign(data.bgdeltaString),
            bgdeltaColor: UIColorChanger.getDeltaLabelColor(data.bgdelta),
            bgdeltaArrow: data.bgdeltaArrow,

[poml88]

Ah, and the blurred background can be achieved with: AccessoryWidgetBackground()

[dhermanns]

Hi Phil. Great hints. The bgdeltaArrow isn't updated and therefore not displayed right now.

If you can get the timer working, PR is appreciated.

[poml88]

I did set up a build enviroment. I built the latest version and am waiting if I can get the testflight vor external testing reviewed. Then I can play a bit. I have a few more questions, I will ask in another place.

[poml88]

Ok, Thanks for the bgdeltaArrow advice. I am planning to make some FSL3 optimized version of NG, maybe just one configuration switch "FSL3 yes/no" or so.

[dhermanns]

If you wan’t to add minute based updates, I would prefere preference switches for each feature. Like “Check for updates any minute (yes/no)”.

Because I would expect more and more sensors will switch to more recent updates.

Phil @.***> schrieb am So. 31. März 2024 um 22:28:

Ok, Thanks for the bgdeltaArrow advice. I am planning to make some FSL3 optimized version of NG, maybe just one configuration switch "FSL3 yes/no" or so.

— Reply to this email directly, view it on GitHub https://github.com/nightscout/nightguard/issues/277#issuecomment-2028896796, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAYPBFO4F3JTAT6YJ4ZPRMDY3BWVVAVCNFSM6AAAAABBUX4JLSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMRYHA4TMNZZGY . You are receiving this because you modified the open/close state.Message ID: @.***>

[poml88]

Sorry to come back to this, but does the entries v1 api not deliver the "direction"?

[
  {
    "type": "string",
    "dateString": "string",
    "date": 0,
    "sgv": 0,
    "direction": "string",
    "noise": 0,
    "filtered": 0,
    "unfiltered": 0,
    "rssi": 0
  }
]

[poml88]

So, if I get some entries via https://nightscout.cmdline.net/api/v1/entries.json then it does provide the arrow, does it not?

{"_id":"660aa97cfae3e1519455056f","type":"sgv","sgv":108,"direction":"Flat","device":"nightscout-librelink-up","date":1711974755000,"dateString":"2024-04-01T12:32:35.000Z","utcOffset":0,"sysTime":"2024-04-01T12:32:35.000Z","mills":1711974755000}

[dhermanns]

Yes - the api provides this. The problem was that my internal NightscoutService wasn't designed to retrieve the direction in the method readChartDataWithinPeriodOfTime.

This could be changed, but would mean quite some redesign. So when changing this, I would like to switch to the new nightscout v3 api. That would have to be done sooner or later...

[dhermanns]

A quick hack would be to add the direction to the BloodSugar class.

[poml88]

I agree it woule be best added while moving to the v3 api. More interesting could be the timers to have less calculation to find out how old the values are (current time -- time of widget update -- age of value) :-)

[poml88]

Question: The delte of the BG values that is displayed, how is that calculated? Is that the last 5 values, or last 10 minutes, or...?

[dhermanns]

Its the difference of the value before. So right now the delta during the last 5 minutes.

[poml88]

Ah, ok. Since the Libre reports 5 values in that 5 minutes I was a bit confused.

[dhermanns]

So, I would expect 5 minutes there, too. Since the delta of 1 minute makes not so much sense. But just a wild guess, since I'm not using Freestyle. The delta is retrieved via backend in just all cases.

The only exception from this is right now during background updates. There I'm calculating the delta on my own right now. But should be removed there too, when switching to V3.

[poml88]

I guess for FSL2/3 users it would be interesting to get this nororious arrow there, maybe instead of the delta. It is a good indicator how quickly things are changing. I agree that a delta of 1 minute is quite useless. :-)

[dhermanns]

Don't introduce UI differences depending on this feature. It will be hard to test if there is a different rendering whether 1 minute updates are enabled or not.

At least I won't expect that the arrows are rendered just in the case ;-)

[poml88]

I do not plan to play with the UI... Well, on the watch app main screen I would prefer to make the arrow a bit larger. Maybe re-arrange the delta, arrow, and time, it is quite small. And there seems to be a bit of space to the right of it.

[poml88]

Hi, ok, I made quite a lot of progress on this. It is really just adding one line or so, nothing complicated.

• I have added the AccessoryWidgetBackground() to the supported widgets. That makes it much easier to read at least on my phone, because I have a picture of the dog as the background. For people with simple background it is not necessary. We could of course add an option to the preferences to switch these backgrounds on and off. Then people can decide.

• The timers are working just fine on watch and phone. Very simple. I have chose the "offset" type for the moment see these examples, perfect. I think, for the rectangular we can even omit the 4th line, or add a 4th value, because each time the widget refreshes, we could calculate the age and then the timer will start from there, so we would see every second how old each value is. Much better already, it says now "+8 minutes" instead of some time...

• There is something: For the FSL3 people who have 1 minute updates it might even be better to calculate some sort of average of the last 0-5, 5-10, 10-15 minutes, to get some more useful info? On the other hand, if we could hack the notorious arrow in, as discussed above, that would be enough.

• I was also wondering if it was not better after 30 minutes or so, to change very old values to "---" instead of still showing them. Would make it much clearer, that they are useless now.

• Is it possible to re-open this thread?

[dhermanns]

2) If offsets are working fine, Line 4 could indeed be removed - great! The 4th line caused clippings under circumstances.

3) Some kind of summarized visualization would be great for 1minute updates.

4) I would not remove the values. Even if 30min old, a 300 would mean something different to me then a 120 ;)

[poml88]

1. This background is adaptive, so I am not sure it has to be in the preferences. Some people would need to try it out, it is working fine for me.

An adaptive background view that provides a standard appearance based on the the widget’s environment. The system only displays this view inside a WidgetFamily.accessoryCircular, WidgetFamily.accessoryCorner, or WidgetFamily.accessoryRectangular widget. In any other context, the system displays an empty view instead.

2. Indeed, the box is very full, to get rid of the 4th line would be good. The question is how to format the timer. The shortest one is a simple timer "9:59", I prefer the "+9 minutes" one but it is long. But it can be clipped, but then it could shoe "min" "mi" or m" or anything in between. It is a bit difficult to test for me, because the widget preview is incredibly slow and does not work for me. I did not manage to have my watch show up in xcode as well, I can't access the developer mode on it. But I guess this is because I don't own a Mac...

3. That needs some thinking.

4. Ok, it does not harm. There could be a preference though "remove old values", easy.

[poml88]

There is this TestFlight Version if someone wants to try out the new timer and backgrounds.

[dhermanns]

The background of the widget looks quite strange on my wallpaper. I would prefer at least a transparent background with rounded corners.

The auto updated time is amazing. It would be great to have the time for each bg value adjusted. And the 4th line would be obsolete.

Great work 👍

[poml88]

You mean the rectangular widget? Yes, the background is very sharp and rectangular at the moment. Needs a bit more work.

[poml88]

It is tricky to format the timer... At the moment you have 1m, 2m, 3m, the timer is dynamic, so not easy to clip I think. Any ideas? I will update the code in my fork.

Also time consuming, because the preview does not work, for iOS 17 it always wants this stupid .containerBackground(for: .widget) and I am trying to implement that, but still the preview does not work. Rubbish...

[poml88]

So, I need some advice for the timers, they are running, but how to format? It is a bit tricky. I made an example app where the preview works. In the NG app I cannot get them to work. Here two screen shots. There are three timers: .timer, .offset, .relative. See the examples in a post above.

[dhermanns]

When looking into your examples I think all output is much to long. What looks promising is to use a .timer style instead.

[poml88]

Yes, but then the display is full of numbers everywhere, and they all change every second. Very busy.

[dhermanns]

Would be enough for the first value. Second could be +5m and so on.

[poml88]

As far as I understood these timers are not really formattable. The first line could be .timer the other two .relative or so. But then it is inconsistent.

[dhermanns]

Yes. I would just hardcode the second line as static +5m

[poml88]

But with widget update every 15 min or so that can lead to strange results.

[dhermanns]

Why? Should look like

15:21 102-5 +5m 107+0 +10m 107-2

[poml88]

Maybe this is too complicated by email ;-) Because we are combining two ages here: The age of the entry and the age of the widget. Maybe I am too stupid. :-)

So: Line 1: timer starts at 0 widet age + X entry age Line 2: static at widget age + entry age? Line 3 same as Line 2?

[dhermanns]

Line 2 just relative age to line 1. Line 3 the same.

[poml88]

Ah, ok, maybe I get it. But then we have the calculation again as with the time... 15 min+ 5 min, ok, much less complicated, but I liked the idea of having the exact age at every line.

[dhermanns]

Only option seems to be .timer. If used for all lines gets indeed more noisy.

[poml88]

So you don't like the shortened lines with 1 mi... 10 m.... 2 hrs.... ?

[dhermanns]

Looks ugly ;-)

[poml88]

Yeah, I am more the pragmatic type. But hey, I can make a pull request and then you can play with it...