When thinking about your app data, one aspect to consider is data lifetime. In general, when it comes to the lifetime of data, you have two options:
local data, which
exists as long as the app that created it remains installed, and roaming data, that will continue existing online even after your app is uninstalled. If you want your data to be roamed/synced and live independently of a single app installation you have different options available, such as the roaming app data feature discussed in the recent blog post series on that topic or by using a cloud data provider, such as OneDrive or Azure.
In today’s blog post, we will talk about local data, or data that is tied to the specific device where it was created. We will be looking at the different features that the Universal Windows Platform provides you with to do this, examples, and best practices.
Types of app dataThere are two types of app data: settings and files.
- Settings. Use settings to store app state and user preferences. The Universal Windows Platform (UWP) provides APIs to easily store and retrieve settings. The data types you can use in app settings are:
- UInt8, Int16, UInt16, Int32, UInt32, Int64, UInt64, Single, Double
- Boolean
- Char16, String
- DateTime, TimeSpan
- GUID, Point, Size, Rect
- ApplicationDataCompositeValue—a set of related app settings that must be serialized and deserialized atomically
- Files. Use files to store binary data or to serialize your own custom types.
Storing app data locallyWhen an app is installed, the system creates a per-user app data container on the device. This app data container is within the app sandbox, which means no other app will be able to access it. The system will preserve the content of the data container when the app is updated and will remove it when the user uninstalls the app.
As a developer, you have three locations available in the app data container to store data locally:
LocalLocal can contain both files (LocalFolder) and settings (LocalSettings) and should be used for any information that is of user value and can’t easily be recreated or downloaded. Data stored in Local can be backed up by the system if the device supports App Data Backup. Because of this, you should avoid using Local to store cached or temporary files that you could create or fetch again on demand.
App Data BackupDuring a device backup operation, the system will grab any app data in Local and store it as part of a device backup image in OneDrive. If the user resets or replaces the device, he or she will be given the choice to restore a previous backup, which will restore the app data in Local as part of the app’s installation. Note that by not storing data in Local you will effectively be opting out of backup for your app.
Best practices for Local- Use for data with user value that can’t be recreated or downloaded by your app. If you place cached content or throwaway data in Local you are wasting user storage on OneDrive and delaying how long it takes to install your app during a device restore.
- Use for settings that are unique to a device.In general, it is desirable to have common user settings on all of the user’s devices. However if you have settings that you don’t want roamed you should store them in Local.
- Do not store credentials in Local.In order to offer the best user experience around credentials you should be using the Credential Locker feature.
- Avoid it for data tied to specific hardware.If you have data that can only be consumed on the same physical device where it was created do not place in Local, because the user may choose to restore this data to a different device. One example of data tied to specific hardware is anything derived from device ID.
Using LocalFolderTo read or write files in LocalFolder, you must use the ApplicationData.LocalFolder property; you will get back a StorageFolder. You can then use StorageFolder.CreateFileAsync and StorageFolder.GetFileAsync to write and read files.
