So I'm thinking of adding a health event once per minute, that updates with health stats (eg steps, movement) over that minute (and the ability to query health stats for what has happened during the minute). That way apps can hook onto that event and nothing is treading on anything else's toes.
Won't this drain a lot of battery?
Could the firmware not manage the reset at midnight as per current locale setting ?
Apps would be much simpler if we could just do Bangle.getSteps() rather than have to manage a >listenner.
This seems like a complex problem. And this is my first time thinking about it, but maybe this could work:
From my understanding the midnight reset becomes an issue only when some app is counting steps during a reset. What if apps that rely on step counting had a way to tell the firmware they are still counting? Specifically, if an app is counting steps, it would have to write "1" (or a timestamp, or even just the equivalent of GNU touch) to a .keepalive file. At midnight, the firmware only resets steps if the .keepalive file was modified more than 1 minute ago, otherwise, delay the reset for 5 minutes. Unless there is a better way to determine whether any app is accessing the step count?
Another alternative would be to have the firmware write the step count to 2 files/variables at the same time. These files/vars would be named with the date (ddmmyyyy or similar, just something that changes every day in a predictable manner), and steps always get added to both "today" and "yesterday". Apps that read steps define on startup from which variable they are reading the step counts. Firmware step reset only deletes the file/variable "2 days ago".
I would think both these approaches are less resource intensive than polling every minute (which will not only make apps more complicated, but also report the step information with a 1min delay).
I have never done embedded development before, so these ideas might just be dumb/naive, but I thought they could maybe be helpful. Don't be afraid to tell me how dumb they are, if that is the case. =-)
Espruino is a JavaScript interpreter for low-power Microcontrollers. This site is both a support community for Espruino and a place to share what you are working on.
Won't this drain a lot of battery?
This seems like a complex problem. And this is my first time thinking about it, but maybe this could work:
From my understanding the midnight reset becomes an issue only when some app is counting steps during a reset. What if apps that rely on step counting had a way to tell the firmware they are still counting? Specifically, if an app is counting steps, it would have to write "1" (or a timestamp, or even just the equivalent of GNU
touch
) to a.keepalive
file. At midnight, the firmware only resets steps if the.keepalive
file was modified more than 1 minute ago, otherwise, delay the reset for 5 minutes. Unless there is a better way to determine whether any app is accessing the step count?Another alternative would be to have the firmware write the step count to 2 files/variables at the same time. These files/vars would be named with the date (
ddmmyyyy
or similar, just something that changes every day in a predictable manner), and steps always get added to both "today" and "yesterday". Apps that read steps define on startup from which variable they are reading the step counts. Firmware step reset only deletes the file/variable "2 days ago".I would think both these approaches are less resource intensive than polling every minute (which will not only make apps more complicated, but also report the step information with a 1min delay).
I have never done embedded development before, so these ideas might just be dumb/naive, but I thought they could maybe be helpful. Don't be afraid to tell me how dumb they are, if that is the case. =-)