Holding application state

If I want a device to keep a state that will be used and updated while running (hold status variables etc), I see this can be done in different ways. The “store” can be used (this.getStoreValue, this.setStoreValue etc in a Device class), I have also seen apps using the ManagerSettings.set / ManagerSettings.get for this as well, maybe there is other places to store application state as well?

Since the documentation does not say very much about the different choices other than listing the technical details, can anyone explain what these different options is supposed to be used for? And which of them remember even when the app shuts down/restarts, which of them is fastest (to avoid slow logic when it includes updating the state).

The per-device settings (Device#getSettings()/Device#setSettings()) are meant for per device, user configurable, configuration data. You can create a configuration page that uses them from app.json, as explained here.

The per-device store (Device#getStoreValue()/Device#setStoreValue()) is meant for per device, internal-use configuration data.

For instance: say that your device has to be accessed through an IP-address. That’s a per-device setting, because the user should be able to change it. Say that you also want to store the current firmware version of the device for some reason. That’s something internal to your app, not meant for users, so you would use the store for that.

ManagerSettings (or this.homey.settings in SDKv3) is used for per-application settings. You have to create a custom settings page for them as explained here.

For example: your app uses a cloud service that requires user credentials to log in. Those credentials are stored in the per-app settings.

I don’t think there’s much of a performance difference between any of the methods, and all of these will survive an app (or Homey) restart.

1 Like