Storing and retrieving state efficiently (HTML)
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.
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.
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.
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.
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.
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.