Save settings to lfs and restore on initial boot

[tahnok]

trafficstars

This saves the settings register to a settings.bin file on the lfs filesystem so that your settings persist across battery changes

I'd like to copy this pattern and apply it to the location and birthday "settings", which should be straightforward, and then find a way to save the date as well

[joeycastillo]

I love this idea! Two notes:

1. I worry about writing the file every time the preference face resigns. I'm worried that it will cause wear to the Flash to rewrite it that often (especially because it resigns every time you loop through all your faces to get back to Clock).
2. Technically, other watch faces can change settings (i.e. the temperature watch face toggles the Imperial/Metric setting).

I think resolving 1 would be enough for now; in the future I think it might make sense to refactor changes to settings into a function call, rather than passing that pointer around with every watch face callback.

[joeycastillo]

One option that could solve both issues: rather than doing it in the watch face, have Movement hang onto the old values of the first four registers and then check them against their previous values once a day (i.e. at midnight). If a setting has changed, write the registers to the file; if not, it's a no-op.

[tahnok]

Ya, the midnight thing fixes it, although we could just read the value from the file and check if it's different before writing?

I might make a new file with some save/restore methods that you could call whenever you changed things you might want to persist? That would let various faces call it

[joeycastillo]

I think that makes a lot of sense! Maybe functions to read, set (in the register) and store the settings? That would be a smarter way of allowing watch faces to interact with the settings than what we currently do (passing a reference to the settings to the watch faces). Adding these functions would be a great step toward refactoring that out at some point.

[tahnok]

Updated with a check to see if there's anything new to write and skipping if it's already saved

Before I go off and write stuff, where you thinking of hiding all the settings read/write behind methods? I was just kind of imaging a movement_persist_settings method you are supposed to call after touching anything that's responsible for putting things in the backup register and writing to LFS. I only see 4 places that update the settings register (set_time, preferences and 2 thermistor faces)

[joeycastillo]

Before I go off and write stuff, where you thinking of hiding all the settings read/write behind methods?

I was thinking of doing this because of a refactor I want to do eventually. Specifically: I regret Movement passing in a movement_settings_t *settings to every watch face callback, i.e. I'd like to replace all

watch_face_loop(movement_event_t event, movement_settings_t *settings, void *context);

functions with

watch_face_loop(movement_event_t event, void *context);

and have watch faces interact with the settings with functions like:

movement_settings_t movement_get_settings(void);
void movement_update_settings(movement_settings_t settings);
void movement_persist_settings(void);

. Writing these three functions would be a good first step toward that refactor, and if you're already going to be in those four spots where settings get changed, it would be rad to wrap those changes in function calls and add the persistence. Then there would be no need for that extra function parameter, which could be removed in a later PR that tweaks all the current watch faces' callbacks.

[synthead]

What if we versioned the preferences somehow? We could default every watch face to implied version 1, and the faces can specify version 2, 3, etc. as necessary. Then, when saving and restoring the preferences, it'd save as version 1, and restore as version 1.

Let's say we also have annoying_alarm.h that had some changes and does not have backward-compatible changes with the stored config. If it was aware of the local changes, then it would have a routine where it inspects the preferences, sees version 1, transforms it to version 2, and saves the new settings.

Alternatively, for safety's sake, we could also ignore saving or recalling preferences for faces that doesn't have a version configured. We could also utilize the reset button to clear the settings file too, if we'd like.

Just throwing things at the wall :smile: I love the idea of saving and recalling preferences to a file!