Données utilisateur et données d’application

Données utilisateur et données d’application

[ Cet article est destiné aux développeurs de Windows 8.x et Windows Phone 8.x qui créent des applications Windows Runtime. Si vous développez une application pour Windows 10, voir la Documentation ]

Les applications Windows Runtime utilisent un certain nombre d’emplacements de stockage des données utilisateur et de l’application. L’emplacement idéal pour stocker les données dépend du scénario et du langage que vous choisissez pour créer votre application. Nous présentons la gamme complète des supports de stockage et nous mettons en évidence les scénarios les plus adaptés pour chaque support.

Types de données d’application

Il existe deux types de données que les applications gèrent ou avec lesquelles elles interagissent fréquemment :

  • Données d’application

    Données que l’application crée et gère elle-même. Il s’agit de données mutables spécifiques aux fonctions internes ou à la configuration d’une application particulière. Elles incluent l’état d’exécution, les préférences des utilisateurs, le contenu de référence (par exemple les définitions du dictionnaire dans une application de type dictionnaire), ainsi que d’autres paramètres. Les données d’application sont liées à l’existence de l’application et n’ont de sens que par rapport à cette dernière.

  • Données utilisateur

    Données que l’utilisateur crée et gère quand il se sert d’une application. Elles incluent les fichiers de documents ou multimédia, les transcriptions de courrier électronique ou de communication, ou les enregistrements de base de données dont le contenu a été créé par l’utilisateur. Notez que les préférences ou les options de configuration d’application sélectionnées par l’utilisateur sont considérées comme des données d’application et non comme des données utilisateur. Les données utilisateur peuvent s’avérer utiles ou judicieuses pour plusieurs applications. Il s’agit souvent de données que l’utilisateur veut manipuler ou transmettre sous forme d’entité indépendante de l’application elle-même, par exemple un document.

Stockez vos données d’application des applications Windows Runtime dans les magasins de données que le système fournit à cet effet, et qui sont spécifiques à l’application et à l’utilisateur. Le système peut ensuite gérer ces magasins de données et les isoler par rapport aux autres applications et utilisateurs. Le système conserve ces magasins de données lorsque l’utilisateur installe une mise à jour de l’application. Le système supprime également le contenu de ces magasins de données, de manière complète et propre, quand l’utilisateur désinstalle l’application. Ne stockez pas les données d’application dans des emplacements de stockage destinés à des données utilisateur afin de contourner ces caractéristiques.

Comme la durée de vie des magasins de données d’application est liée à la durée de vie de l’application, ne stockez pas les données utilisateur telles que les documents ou les éléments multimédias dans des magasins de données destinés à des données d’application. Utilisez les bibliothèques de l’utilisateur et Microsoft OneDrive pour stocker ce genre d’informations.

Les tableaux résument les divers emplacements de données disponibles pour votre application, leurs limites et leurs utilisations recommandées. L’accès à certains emplacements de données est limité dans les applications Windows Runtime en JavaScript, selon le contexte du document. Toutes les limitations relatives à la taille de stockage sont également dépendantes de la taille totale du support de stockage.

Données utilisateur

Emplacement de donnéesDisponible pourFonctionnalités et limitationsUtilisation recommandée

Bibliothèques accessibles à StorageFile et aux file pickers de Windows Runtime

  • Applications Windows Runtime en JavaScript (contexte local)
  • Applications du Windows Store en C++, C# ou Visual Basic
  • Applications du Windows Store en C++ basées sur DirectX
  • Charger et enregistrer des fichiers dans les bibliothèques de l’utilisateur
  • API asynchrone
  • Aucune limite de taille
  • Sélecteurs de fichiers et de dossiers :
    • Utilisez les sélecteurs de fichiers et de dossiers pour permettre à l’utilisateur de contrôler la sélection ou la création du fichier.
  • Accès programmatique :
    • Nécessite une fonctionnalité dans le manifeste du package pour chaque bibliothèque, à l’exception des téléchargements où une application est autorisée à écrire ou lire ce qu’elle a écrit.
    • Nécessite une extension du type de fichier souhaité dans le manifeste du package pour les fichiers qui peuvent être ouverts pour Documents ou les emplacements de stockage amovibles.

À recommander pour les données utilisateur destinées à être conservées au-delà de la durée de vie de l’application ou qui sont gérées de manière indépendante par l’utilisateur.

OneDrive

  • Applications Windows Runtime en JavaScript
  • Applications du Windows Store en C++, C# ou Visual Basic
  • Applications du Windows Store en DirectX
  • Prend en charge le stockage des données utilisateur dans le cloud et est disponible pour plusieurs plateformes de périphériques
  • API REST et JSON (JavaScript Object Notation)
  • Se limite à une liste bien définie de formats de fichiers pris en charge
  • Permet l’accès au contenu partagé par d’autres utilisateurs
  • Quota de taille basé sur le compte d’utilisateur

À recommander pour les données utilisateur auxquelles l’utilisateur veut accéder à partir de plusieurs périphériques, plateformes ou applications.

API de fichier HTML5

  • Applications Windows Runtime en JavaScript (contexte Web et contexte local)
  • Applications du Windows Store en C++, C# ou Visual Basic
  • Applications du Windows Store en DirectX
  • Norme Web

À privilégier uniquement pour les scénarios impliquant le téléchargement entrant et sortant de fichiers. Pour les transferts qui se poursuivent pendant que l’application n’est pas active, utilisez le BackgroundTransfer de Windows Runtime à partir du contexte local.

 

Outre les options de stockage décrites dans ce tableau, vous pouvez aussi utiliser des solutions tierces de stockage dans des bases de données et le cloud.

Données d’application

Emplacement de donnéesDisponible pourFonctionnalités et limitationsUtilisation recommandée

API de données d’application pour Windows Runtime

  • Applications Windows Runtime en JavaScript (contexte local)
  • Application du Windows Store en C++, C# ou Visual Basic
  • Application du Windows Store en DirectX
  • Fournit un magasin de données local et un magasin de données itinérant
  • Fournit également un magasin de données temporaire soumis à un nettoyage de disque par le système
  • Prend en charge le contenu fortement structuré (paramètres)
  • Prend en charge les types composites (ensemble de paramètres gérés comme une unité atomique)
  • Prend en charge les données non structurées (fichiers)
  • Les paramètres utilisent une API synchrone
  • Les fichiers utilisent une API asynchrone
  • Les paramètres sont limités à 8 Ko par paramètre ou 64 Ko par paramètre composite ; il n’y a aucune limite au nombre de paramètres. Nous vous conseillons de stocker moins de 1 Mo de données
  • Les fichiers n’ont aucune limite de taille
  • Les fichiers et paramètres itinérants sont limités au niveau de leur taille totale dans chaque package, comme cela est défini dans ApplicationData.RoamingStorageQuota ; dans le cas contraire, l’itinérance n’a pas lieu
  • Le système gère le moment où a lieu l’itinérance, afin de préserver la bande passante et l’autonomie de la batterie. L’itinérance du paramètre HighPriority s’effectue à une fréquence plus élevée que les autres paramètres.
  • Aucune limite de taille sur les données temporaires

À recommander pour les paramètres et les fichiers de données non structurées.

IndexedDB

  • Applications Windows Runtime en JavaScript (contexte Web et contexte local)
  • Technologie de stockage ISAM
  • Navigation par curseur indexé ou séquentiel
  • Stockage limité à 250 Mo par application
  • Pour les lecteurs de moins de 30 Go, le stockage est limité à 375 Mo parmi toutes les applications installées
  • Pour les lecteurs de 30 Go et plus, le stockage est limité à 4 % de la taille du lecteur ou 20 Go, selon la valeur la plus petite, parmi toutes les applications installées
  • Les pages de contexte Web n’utilisent que IndexedDB si l’URL de la page se trouve dans la partie ApplicationContentUriRules du manifeste du package de l’application à moins que vous ne définissiez la balise meta ms-enable-external-database-usage sur la page d’accueil de l’application

À recommander pour le stockage de données structurées et indexées utilisables uniquement par JavaScript. Convient principalement aux scénarios de mise en cache.

ESE (Extensible Storage Engine)

  • N’importe quelle application ; toutefois, un développeur doit inclure dans un wrapper les appels d’un objet Windows Runtime pour permettre son utilisation par des appelants qui ne sont pas en C/C++
  • Technologie de stockage ISAM
  • Navigation par curseur indexé ou séquentiel
  • Données transactionnelles
  • Cohérence robuste des données, même en cas de blocage du système
  • Données mises en cache pour une récupération rapide
  • Adaptable à de grandes tailles, généralement au-delà de 50 Go
  • Stockage dans un fichier binaire plat, placé sur le disque par d’autres moyens, par exemple les API ApplicationData de Windows Runtime
  • Seules les API C/C++ sont fournies

À recommander pour le stockage de données structurées et indexées utilisables par les langages C/C++ ou incluses dans un wrapper au sein d’un objet Windows Runtime créé par un développeur.

Stockage Web HTML5

  • Applications Windows Runtime en JavaScript (contexte Web et contexte local)
  • Application du Windows Store en C++, C# ou Visual Basic (utilisation du contrôle WebView)
  • Utilise les paires clé-valeur des chaînes
  • Norme Web
  • Isolement par rapport au cache du navigateur en fonction de chaque utilisateur et de chaque application
  • API synchrone
  • Limite de taille de 10 Mo

Utilisez localStorage quand vous avez besoin d’un stockage léger dans un contexte Web et que Windows Runtime n’est pas disponible. N’utilisez pas sessionStorage, car il n’existe qu’en mémoire et n’est pas conservé en cas d’arrêt de l’exécution de l’application. Ne l’utilisez que pour un stockage momentané peu susceptible d’être interrompu par l’utilisateur qui bascule vers une autre application.

WinJS.Application.sessionState

  • Applications Windows Runtime en JavaScript (contexte local)
  • Objet JavaScript avec des propriétés définies par l’application
  • Enregistrement automatique par la Bibliothèque Windows pour JavaScript en cas d’interruption dans le ApplicationData local
  • Aucune limite de taille.

À privilégier uniquement comme emplacement de stockage de l’état transitoire de l’application quand cette dernière est interrompue et qu’elle s’arrête, afin de permettre la reprise de son exécution dans le même état.

Stockage d’état WinJS.Application.local

  • Applications Windows Runtime en JavaScript (contexte Web et contexte local)
  • Wrapper de commodité pour ApplicationData
  • Revient par défaut à une implémentation en mémoire dans un contexte Web

À recommander pour le code JavaScript qui doit s’exécuter dans un contexte Web et un contexte local.

Stockage d’état WinJS.Application.roaming

  • Applications Windows Runtime en JavaScript (contexte Web et contexte local)
  • Wrapper de commodité pour ApplicationData
  • Revient par défaut à une implémentation en mémoire dans un contexte Web

À recommander pour le code JavaScript qui doit s’exécuter dans un contexte Web et un contexte local.

 

Outre les options de stockage décrites dans ce tableau, vous pouvez aussi utiliser des solutions tierces de stockage dans des bases de données et le cloud.

Serveur

Quand votre application interagit avec des sites Web et des services Web, d’autres emplacements de stockage de données peuvent être utilisés :

Emplacement de donnéesDisponible pourFonctionnalités et limitationsUtilisation recommandée

Cache d’application HTML5

  • Applications Windows Runtime en JavaScript (contexte Web et contexte local)
  • Application Windows Runtime en JavaScript (basée sur un manifeste de cache d’application Web)
  • Norme Web
  • Permet la prérécupération du balisage d’application, des scripts, des feuilles de style et des ressources Web pour faciliter l’utilisation hors connexion
  • Les pages du contexte local ne peuvent utiliser qu’un cache d’application Web pour récupérer les ressources qui ne contiennent pas de code. Par exemple, vous pouvez vous en servir pour récupérer des images, du contenu audio, du contenu vidéo ou du contenu xml pour une utilisation hors connexion.
  • Impossible à écrire via un script
  • Pour qu’une page du contexte Web puisse accéder au cache d’application, l’URL de la page doit être ajoutée à la partie ApplicationContentUriRules du manifeste du package de l’application. Ce critère ne s’applique pas aux pages du contexte local.

À recommander lorsque le contenu est en lecture seule, qu’il est fourni à partir d’un serveur Web et qu’il doit être accessible pendant que l’appareil est hors connexion. Bien que le cache d’application HTML5 puisse être utilisé pour fournir du contenu personnalisé, il est avant tout conçu comme une stratégie de mise en cache pour l’accès hors connexion aux données.

Cookies

  • Applications Windows Runtime en JavaScript (contexte Web et contexte local)
  • Application du Windows Store en C++, C# ou Visual Basic (utilisation de WebView)
  • Applications utilisant IXMLHTTPRequest2
  • Norme Web
  • Isolement par rapport au cache du navigateur en fonction de chaque utilisateur et de chaque application
  • Limite de taille de 4 Ko par cookie ; nombre de cookies illimité
  • Les cookies à destination et en provenance d’une page du contexte local pour le Web via XHR sont soumis aux règles de partage classiques des cookies entre domaines pour le Web

À recommander pour les données qui doivent être partagées avec chaque requête vers un serveur Web.

Services cloud, services OpenData et bases de données cloud

  • N’importe quelle application
  • Permet de tirer parti d’une solution complète de base de données cloud
  • Permet le traitement par déclenchement côté serveur ou périodique
  • Les fonctionnalités dépendent de l’adoption du service cloud

À privilégier quand vous utilisez un contenu volumineux, généré par une source tierce, ou qui s’affiche à la fois sur un site Web et dans l’application.

 

 

 

Afficher:
© 2017 Microsoft