bangle.js - collect data into memory that survives widget reload

Hi,
I'm a first timer here. Fantastic project! I wasn't even looking for a smartwatch, but just had to have one, when I saw it :) .

I'm trying to store barometer data for the past few hours (to indicate rising/falling pressure on a watch face).
Current approach : use a widget as a background service. Using a timer, I power up the pressure sensor once or twice per hour, and store the data in a buffer (using fixed-size typed array in a ring-buffer fashion). The array buffer lives in the scope of the widget. Since the widget isn't graphical, it just has width=0 and an empty draw() function.
However, whenever I leave the watch face, e.g. to open an app or go into settings, the widget seems to be reloaded. The buffer seems to have gone out of scope and gotten garbage-collected, as in the init code of the widget, it is undefined. I'm guessing that the WIDGETS global variable is

I did a workaround where I write the buffer to flash storage each time I add a value, then re-initialize from that file when loading the widget. But it seems odd to be constantly writing to flash all the time, especially when it's data that is (relatively) short lived. But it does need the history of the past 1-2 hours to make sense.

• Is there any way to make a service like this in bangle.js? Meaning something that starts when the watch is started, so that a variable may survive widget reloads?
  
• Or as a backup plan - is there any way I can hook up to an event before the WIDGET variable is nuked, i.e. before widgets are loaded? That way I could save data to file only on that occasion, instead of scratching the flash constantly.
  
• Or, as a backup plan, I guess I could use my own global variable to store the buffer. That feels a bit dirty, however. Would that be considered good practice (I'm not very experienced in javascript programming...).
  
  

A bonus question, slightly related : Is there any event one could hook to, that fires before the watch is reset? Also with saving data to permanent storage in mind.

btw - I'm running on fw 2v12.70

Greetings, and thanks for a fantastic project!
Indriði

When you change app (e.g. go to settings which is also an app) then all variables, including globals, are deleted and new app starts from empty state. Only way to save data beyond that is to use flash.

You can use kill event to save data when your widget is about to get shut down:

E.on('kill', () => {
  // save data to flash
});

When you open an app, basically the whole watch is reset and then loads the app, so you'll definitely need to store those values to flash.
I think you're looking for the E.kill event, although if you only sample once or twice an hour it might not be worth bothering with, and just write to flash immediately.

I also think you might want to change it from a widget into boot code: that runs at every boot, instead of only for apps that load widgets.

Edit: well, malaire beat me to it ;-)

Hi - I think the others have covered this just fine, but just to clarify:

In Bangle.js, everything is ripped down when you change apps. There is no way to store a variable that persists so the kill event is the best option - if you write the same file to storage as before, the write will be ignored so it's not too bad.

There may be persistent vars in the future, but the relatively restricted nature of the device means that any app with a memory leak would effectively make the watch unusable - and given the amount of time I spend supporting people who installed apps that broke their watch right now, I feel pretty confident that I'd regret adding it at the moment :)

There may be persistent vars in the future, but the relatively restricted nature of the device means that any app with a memory leak would effectively make the watch unusable ...

Such a feature should definitely have some kind of per-app limit for persistent data size. Perhaps a max size in bytes in metadata.json or in settings?

per-app limit for persistent data size

Thing is we're on a very constrained system - if every reboot we have to load all the app.info files and parse them for data, then count it all and check, it's going to make app loads even slower. And I'd go to all that effort and someone would just put 10,000 in for their per-app limit in the metadata anyway :)