Open datacompboy opened 1 year ago
I admit, I'm intrigued by the fact that Fitbit exposed the SpO2 metric at the end of 2022, I wasn't aware of it, so feel free to chip in with thoughts. I'm open to the idea, but here are my thoughts.
Fitbit Sense and Versa are pretty much 90s computers, so they require optimization and all that. At the end of the day, it would absolutely be battery draining, as you'd be introducing a new display and at least one new condition. That may not sound significant in 2023, but we're in the 90s.
Additionally, If I'm not mistaken, that type of data is exposed only through the Web API (https://dev.fitbit.com/build/reference/web-api/spo2/). Making calls to those endpoints is usually much more draining, and my clock isn't refreshed per day, rather per second or minute. Can't recall which rn... that would mean another condition or worse yet - a loop.
This leaves two options - adding another loop, which would refresh less frequently, or adding a condition that would safeguard the call and prevent it from being called too frequently... now, the first approach isn't realistic and the second is executed every second/minute.
Now... the fact that it's among the Web API data means it would also require implementation of its own... so benchmarking it would take more work than seems reasonable...
I'm thinking about releasing a new version altogether. That way existing users wouldn't be affected.
Hhhmmm... Yes, it's indeed WebAPI only (doesn't make much sense to me). But the value is only updated by app syncing, so it could be updated on phone side and pushed down as a static value to display, similar to the username?
What about showing last night SpO2 as a health bar of a head? :) Since it changes once/day, it shouldn't be battery draining.