Closed poml88 closed 5 months ago
Another issue is, that I cannot align the .timer to .trailing, it will always be on the leading edge.
Hm, my date calculation does not yet work. Are these two timestamps compatible?
Text(entry.entryDate.addingTimeInterval(-bgEntry.timestamp), style: .offset)
No - different Types. Double and Date.
Uff, ok, thanks, let's see when I can figure that out how to calculate...
We are living in Copilot century ;-)
Copilot.microsoft.com
import Foundation
// Create a reference date (e.g., current date)
let referenceDate = Date()
// Define your double timestamp (e.g., 1621939200.0)
let doubleTimestamp: Double = 1621939200.0
// Calculate the time interval (difference) in seconds
let timeInterval = TimeInterval(doubleTimestamp)
// Subtract the time interval from the reference date
let resultingDate = referenceDate.addingTimeInterval(-timeInterval)
// Print the resulting date
print("Resulting Date: \(resultingDate)")
Wow... What did you enter as a question for the KI?
No, the KI seems to be wrong. So the timestamp seems to be something 1716626685 from 1.1.1970, so I have to add the same number (1.1.1970-25.5.2024) and the difference of that is it....
sure - that was just an example of how to subtract the different data types.
I am now at something like this:
var entryTimeInterval = entry.entryDate.addingTimeInterval(-bgEntry.timestamp).timeIntervalSince1970
Text(entry.entryDate.addingTimeInterval(-entryTimeInterval), style: .timer)
But it seems to be off by some thousand seconds.
BTW you are going through the three lines via a ForEach, so it will be difficult to make the first line .timer and the other two static.
Uff, finally fixed the previews, now it is easier to work.
Ok, the solution is
Text(" \(Date.now.addingTimeInterval(-(Date.now.timeIntervalSince1970 - (bgEntry.timestamp / 1000))), style: .timer)")
With the previews much easier to figure out. So, how do we do the formatting?
So, for me, currently this is the best option, I know you don't like it.
Is there a good trick how to deal with the ForEach
, to have the first line .timer and the other two static?
The other problem ist that the .timer will be always on the left... ".trailing" is ignored.
Of course we can make a preference, "classic" and "offset timer with ugly ..."
Ok, it is done, as you asked for. I'll make a testflight.
Looks great
So, how it is currently done is: Line 1 timer = age entry + age widget Line 2 +Xm = timer Line 1 + Xm = age entry 2 Line 3 +Xm = timer Line 1 + Xm = age entry 3
So, in the screen shot the age would be 4m 7m 11m
Latest TestFlight is available.
A quick hack would be to add the direction to the BloodSugar class.
Ok, I see, because the timelineprovider is reading its data like this. And this is only the three needed values. Could add the arrow, right?
NightscoutService.singleton.readTodaysChartData(oldValues: []) { (result: NightscoutRequestResult<[BloodSugar]>) in
BackgroundRefreshLogger.info("TimelineProvider received new nightscout data...")
var bgEntries : [BgEntry]
var errorMessage = ""
if case .data(let bloodSugarValues) = result {
NightscoutDataRepository.singleton.storeTodaysBgData(bloodSugarValues)
bgEntries = bloodSugarValues.map() {bgValue in
return BgEntry(
value: UnitsConverter.mgdlToDisplayUnits(String(bgValue.value)),
valueColor: UIColorChanger.getBgColor(String(bgValue.value)),
delta: "0", timestamp: bgValue.timestamp)
}
Ok, I added the arrow to the BloodSugar class. And a miracle: it works. It is shown on the widgets. So, then I think I have everything implemented from my list.
For me, I do not need these +1 -1 0 really, I can see the difference between those values, but ok, why not.
Cool, in ios17 it is possible to tap a widget and then it refreshes. Super cool. I’ll implement that!
Great. Keep in mind to finish the open features first and provide PRs for them, if you want them in the app. Otherwise big PRs are hard to review.
Sure! I am back to normal life anyway.
So, how do we do? I can commit to my fork. Then you’ll see the changes and can have a look?
Yes - by merging your fork changes in using the PR.
Ok. Just to explain: I cannot do PR from the fork branch I work on directly -- too many changes to build the project locally. I will do that somehow via another branch.
I just thought you wanted to quickly browse though the changes beforehands, but ok, I will come up with one or more PRs.
That is why you normally build each new feature on a new branch. Thats how you get it separated from other modifications on your fork.
So, would it be ok if I made one pull request for the changes so far? Or shall I make individual ones?
Normally you would make one for each feature naming it with the issue number. Github automatically links them to the ticket.
But to keep it easy this time, just do one. Hopefully it isn't too big ;-)
Hi, the PR will come, not forgotten, but I need to find a MAC first, it is too slow on my setup. Meanwhile I am really enjoying the latest improvements. :)
TestFlight is read to go
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?