Add support for watch-specific settings in localStorage#13
Add support for watch-specific settings in localStorage#13Arney wants to merge 3 commits intopebble-dev:mainfrom
Conversation
index.js
Outdated
| localStorage.setItem('clay-watch-' + this.meta.watchToken, | ||
| JSON.stringify(watchSpecificSettings)); | ||
| } | ||
| localStorage.setItem('clay-settings', JSON.stringify(settings)); |
There was a problem hiding this comment.
Should all of these settings be persisted, or only the settings that aren't specific to the watch? It might be better to retain nothing over a setting from the last watch that was configured
There was a problem hiding this comment.
I was in doubt myself. What is the behavior we want when a new watch is encountered.
The current implementation is closest to existing behavior, you inherit the last used settings. But falling back to the defaults would probably be better, also less risk of having an impossible setting based on capabilities (but this should always be verified on the watch side as well).
I'll make the changes.
There was a problem hiding this comment.
Having developer control of this would be the ideal. This proposal changes the way it used to work since the initial release of Clay (at least for the original Pebble/Rebble app [maybe GadgetBridgetoo], the Core Devices appears to do sandboxing for individual watches).
There was a problem hiding this comment.
I haven't noticed the sandboxing when I tested this with the Core app on iOS (switched between Core 2 DUO and a Time Round) with a sideloaded app, but will check again. I do not have an Android phone, so I do not know if it behaves different there (in the old app and in the Core app).
As for the change of behavior, if a developer doesn't set the "persistPerWatch" flag, the behavior is identical to the current implementation, one list of settings for all the watches.
Store each setting either in a watch specific setting or in a global setting. When no setting is stored for a watch-specific key, clay will use the default value.
use 'fallback' instead of 'default' to better describe this (theoretical) situation
|
tested it in a dummy watchface with Core iOS app and behaves as expected (removing Draft) |
3 participants
No description provided.