Storing Data

There are multiple ways to save data in a mos. application. There is a difference between persistent data and volatile data. The former survives an app restart, and includes user settings and db_tables, while the latter is only available during the current run of the app or is even bound to the currently shown view, e.g. variables or forms.

Persistent Data

Persistent data will outlive an app or device restart and is perfectly suited to save longterm data for your app or to increase the offline capability of your app. A large part of persistent data are db_tables, which are covered on the corresponding page of the basic components.

User Settings

User Settings are key-value pairs that can get accessed by their key.
The only way to set the data, is to use the setValueToUserSetting action. The user setting can then be accessed by its key in multiple ways through evaluables, like in conditions, dynamicParams or dynamicValues.

The user settings are mostly used to store information like JWTs, settings that the user has made (e.g. activated functions such as push etc.) or basic information about the user (e.g. a customer number). In general, the data relates to the user who uses the app (hence the name).

It is also possible to encrypt and decrypt sensitive information in the user settings using biometry. The actions encryptSettingsWithBiometry and decryptSettingsWithBiometry are used for this.

_settings

The _settings table is a predefined db_table in every mos. application. Its structure is as follows:

{
  "name": "_settings",
  "fields": [
    {
      "name": "key",
      "type": "TEXT"
    },
    {
      "name": "string",
      "type": "TEXT"
    },
    {
      "name": "int",
      "type": "INTEGER"
    },
    {
      "name": "real",
      "type": "DECIMAL"
    }
  ],
  "primaryKey": [
    "key"
  ]
}

The _settings table can be used for the same purpose as the user settings, but is easier to use in combination with data in db_tables, as you can join this table on other tables instead of having to first read a user setting and use the value as a query parameter. You can insert data into the _settings table using the executeSQL action.

{
  "type": "executeSQL",
  "params": {
    "sql": "INSERT INTO _settings (key, int) VALUES ('myFavoriteNumber', ?);",
    "sqlParams": [
      "42"
    ]
  }
}

caution

It is a common pitfall to overuse the _settings table table instead of creating other db_tables for the data or using the user settings. It is best, to use the _settings table for data that rarely changes and limit the joins. Otherwise, a high write load on the table combined with many dynamic values and conditions that depend on queries that join the _settings table will severly impact the performance of your app, especially on slower devices.

settingsDataKey

Form layers, such as the textBox layer, can have a settingsDataKey. This results in the content of the textBox being automatically saved in the _settings table, with the settingsDataKey as the value for the key column and the content of the textBox as the value for the string column. Keep in mind that these values are synchronized, i.e. every change is immediately saved in the table and every other change to this row is also displayed in the textBox.

A common use case for this is a local search function where the query of an insert joins the settingsDataKey and is thus automatically updated each time a key is pressed.

_push_history

The _push_history table is a predefined db_table that is disabled by default. It can be enabled in the ./config/app.json file by setting pushHistoryEnabled to true.

By enabling the _push_history table, every push notification received is saved in this db_table. In the pushHistoryMaxAge field, you can enter a duration in seconds after which a push message is deleted, calculated after the message is received. By default, the push history is never deleted. The payload of a push is only saved if pushHistorySavePayload is set to true.

In the pushHistoryQueries field, as in any other db_table, you can define queries to retrieve data within the _push_history table. To be able to execute the queries from anywhere, you need to insert _push_history in the table field where you would normally insert the name of the db_table.

Key	Type	Description	Default Value
"pushHistoryEnabled"	Boolean	The global setting to enable the storage of received push notifications within the app itself.	false
"pushHistoryMaxAge"	Integer	The maximum age of the stored push messages in seconds.	null
"pushHistoryQueries"	Object	Dictionary of named SQLite queries to retrieve stored messages, e.g. "all": {"custom": "SELECT * FROM _push_history"}.	null
"pushHistorySavePayload"	Boolean	Determines if the payload of a messages is stored in addition to the message itself.	false

The _push_history table has the following structure:

{
  "table": {
    "name": "_push_history",
    "fields": [
      {
        "name": "id",
        "type": "INTEGER"
      },
      {
        "name": "title",
        "type": "TEXT"
      },
      {
        "name": "text",
        "type": "TEXT"
      },
      {
        "name": "image",
        "type": "TEXT"
      },
      {
        "name": "category",
        "type": "TEXT"
      },
      {
        "name": "payload",
        "type": "TEXT"
      },
      {
        "name": "date",
        "type": "TEXT"
      },
      {
        "name": "sortDate",
        "type": "TEXT"
      },
      {
        "name": "read",
        "type": "INTEGER"
      }
    ],
    "primaryKey": [
      "id"
    ]
  }
}

The read column is always set to 0. You can easily implement a read/unread feature by writing a query that sets the read value to 1.

Volatile Data

In contrast to persistent data, volatile data is stored in the RAM and is only available as long as the device and the app are running. Specific data is also only available in the current event scope or in the current view.

Global Variables

Variables are best suited for storing session-based information or information that is required across multiple views. They are controlled by the setVariable and clearVariable actions.

Most use cases of variables in mos. are almost like in the user settings, but they should disappear after the app has been killed. For example, if the app should be locked after every restart with biometry, it can be saved in a variable that the user has passed the biometry check. Then you can safely assume that the absence of this variable means that you need to check the biometry again.

Forms

Forms are another way of storing volatile data. Further information can be found in the forms concept page.