Storing and retrieving state efficiently (HTML)

  • Article

There are many different options for storing the state of a Windows Store app using JavaScript. Learn about when to use the different storage options to get the best performance.

When considering the different storage options, keep in mind that each storage or state mechanism requires that the system load additional resources and components. These resources and components increase the overhead of your app, so we recommend that you minimize the number of state and storage mechanisms your app uses.

Session state

For session data, such as global variables core to an app's logic, use the WinJS.Application.sessionState object. This object is an in-memory data structure that is good for storing values that change often but need to be maintained even if the system terminates the process. It's automatically serialized to the file system when the app is suspended, and automatically reloaded when the app is reactivated. By using WinJS.Application.sessionState, you can reduce the number of expensive file operations your app performs.

Roaming settings

Use the roaming data store to store basic app settings, such as color and theme settings. We recommend that you don't use it for settings that are changed often. Use roaming settings for values that don't change often and must be preserved between app launches. For data that change frequently, use session state (the WinJS.Application.sessionState object) instead.

To access the local settings data store, use Windows.Storage.ApplicationData.current.roamingSettings.

Local settings

Use the local data store to store basic app settings, such as color and theme settings. This data store is written to disk (subject to disk caching) when a value changes, and we recommend that you don't use it for settings that are changed often. Use local settings for values that don't change often and must be preserved between app launches. For data that change frequently, use session state (the WinJS.Application.sessionState object) instead.

To access the local settings data store, use Windows.Storage.ApplicationData.current.localSettings.

Local storage

To store large amounts of app data or when you need to save data to a file immediately, use WinJS.Application.local. Don't use local storage to perform smaller reads and writes.

You can access local settings through the WinJS.Application.local or Windows.Storage.ApplicationData APIs.

IndexedDB

IndexedDB provides Windows Store apps using JavaScript with a way to easily store key-value pairs in a database. IndexedDB can handle large amounts of data. Use IndexedDB when you need key-value data management because using it is faster than an implementing your own system. Because using the indexedDB APIs initializes an entire database engine, don't use IndexedDB when you only need to store a few fields. To store smaller amounts of data, use session state or local storage

To access IndexedDB, use the msIndexedDB property.

An example application

To really understand when to use each storage option, let's look at an example app.

Note  This example shows how an app could use every storage option. The example is for illustration only. Due to the memory overhead with loading the binaries associated with each storage option, we don't recommended using every storage option when some can be combined.

 

Consider a basic app that manages a user's contacts. The user can add, remove, and search contacts. For each contact, the user can specify basic info and attach one or more pictures.

Here's a list of which storage options to use for different types of data:

  • Remembering the user's preferences

    The app has preferences the user can change, such as the background color and font size. The app reads these preferences when it's launched and uses them to initialize its appearance. Because the preferences are an essential part of the app and don't change often, use local settings to store this info.

  • Remembering the last contact the user viewed

    The user navigates through different contacts and then switches away from the app. When the user returns later, the app displays the same contact. The last viewed contact changes often. Use the session state to store the last viewed contact.

  • Storing contacts and basic info

    The user wants to easily and quickly search through their contacts. Use IndexedDB to store contact info. IndexedDB is well suited for managing large amounts of data, and provides the quickest way to traverse the data.

  • Storing images of a contact

    Images of contacts can get large, so don't use session state or local settings. Instead, use either IndexedDB or local storage, which allow an app to serialize and retrieve binary data.