Itinérance des données de vos applications

Blog des développeurs d'applications Windows 8

Indications sur la conception d'applications de style Metro pour Windows 8, par l'équipe d'ingénierie de Windows 8

Itinérance des données de vos applications

  • Comments 1

Avec Windows 8, les utilisateurs restent connectés en permanence. Ainsi, ils sont connectés à Internet et à leurs services cloud, mais aussi à leurs autres PC Windows 8. Votre application peut jouer un rôle dans cet écosystème connecté en permanence, en exploitant les avantages liés à l'itinérance des données d'application. Dans ce billet, j'explique en détail en quoi consiste l'itinérance des données d'application, pourquoi cette fonctionnalité est importante, mais surtout comment vous pouvez l'implémenter dans votre application.

Pourquoi diffuser des données en itinérance ?

Les paramètres de personnalisation de l'itinérance jouent un rôle essentiel dans la sensation de connexion permanente qu'offre Windows. Windows 8 diffuse de nombreux paramètres en itinérance : thème du Bureau, arrière-plans, favoris du navigateur, etc. Cependant, Windows ne constitue qu'une petite partie des éléments de personnalisation dont dispose un utilisateur. Les applications constituent la véritable clé de voûte de l'expérience de connexion permanente de Windows 8. Ce sont les applications qui procurent du plaisir aux utilisateurs de Windows et ce sont à ces applications qu'ils consacrent la majeure partie de leur temps. Même si nos applications, notamment Bing Météo et Bing Sports, prennent en charge ces expériences d'itinérance, nous avons besoin de votre aide pour concrétiser notre vision d'un Windows 8 connecté en permanence.

L'itinérance via le cloud est une fonctionnalité vraiment formidable : très pratique pour vos clients, elle permet aussi à votre application de se démarquer. Bien conçue, une application de style Metro avec fonctionnalité d'itinérance permet à l'utilisateur de configurer son application une seule fois et de l'utiliser partout. Ainsi, il n'est pas obligé de reconfigurer l'application à chaque fois qu'il y accède à partir d'un autre PC. Il peut également se connecter où qu'il se trouve, en profitant d'une expérience utilisateur continue lorsqu'il passe d'un PC à un autre.

Comment nous avons simplifié l'itinérance

En matière d'itinérance des données d'application, notre objectif était de faciliter la création d'expériences d'itinérance. Nous avons résisté à la tentation de laisser aux développeurs gérer les mécanismes de synchronisation, car ceux-ci peuvent s'avérer complexes et fastidieux. Nous souhaitions vous aider à diffuser en itinérance tout ce que l'utilisateur est susceptible de configurer.

Pour cela, Windows 8 intègre une fonctionnalité de synchronisation en itinérance pour les données d'application, et ce, pour toutes les applications de style Metro qui utilisent le compte Microsoft connecté, associé à l'utilisateur. Les données d'application se composent de trois types de données, appelés « localités » : les données locales, les données itinérantes et les données temporaires. En écrivant tout simplement ses données dans la localité itinérante, votre application peut faire partie des données synchronisées par le biais du compte Microsoft connecté. Ainsi, vous n'avez pas à vous préoccuper de la gestion de la relation de synchronisation, de configurer une identité et un identifiant, d'acheter ou de gérer un service, ni des autres difficultés habituellement liées à la synchronisation. Windows s'occupe de tout ! Ainsi, il vous suffit de choisir les données à diffuser en itinérance et de savoir comment concevoir votre application pour profiter de ces avantages. Lorsque les utilisateurs se connectent à Windows, ils se connectent également à votre application.

Diagramme montrant comment les données sont transmises entre votre ordinateur, le stockage local et le stockage cloud

Données utilisateur et données d'application

Avant d'aller plus loin, pour mieux comprendre les expériences d'itinérance, il faut bien identifier les différences entre les données utilisateur et les données d'application. Les données utilisateur sont les données créées et gérées par l'utilisateur lorsqu'il se sert de l'application : documents, fichiers musicaux, vidéos, images, etc. Ainsi, il peut s'agir de toute information considérée comme précieuse pour l'utilisateur ou qui peut être partagée entre plusieurs applications. Ce type de données doit être stocké dans l'une des bibliothèques KnownFolder ou diffusé en itinérance à l'aide des API SkyDrive. Les mots de passe doivent toujours être stockés et diffusés en itinérance en utilisant la classe PasswordVault. Dans ce billet, nous nous concentrons sur les données créées et gérées par l'application : paramètres, préférences, état, etc. Le tableau ci-dessous résume les différences existant entre les données utilisateur et les données d'application, et la façon dont elles peuvent être diffusées en itinérance.

Données utilisateur

Données d'application

Utilisables par plusieurs applications

Pertinentes uniquement pour l'application qui les a créées

Documents, musique, images, données exportées

Paramètres, préférences, contexte, état de l'application

Stockées dans le cloud via SkyDrive

Diffusées en itinérance via la classe ApplicationData

Création d'une expérience de type « configure once, use everywhere » (une configuration utilisable partout)

Commençons par une expérience simple de type « configure once, use everywhere ». Supposons que je dispose d'une application consistant en un lecteur simple de flux RSS, permettant à l'utilisateur de lire des éléments à partir d'un ensemble de flux. Lorsque l'utilisateur affiche un flux spécifique, l'application affiche un certain nombre d'éléments par page. Je dispose d'un paramètre configurable par l'utilisateur, appelé ItemsPerPage, qui contrôle le nombre d'éléments de flux à afficher sur chaque page. Je souhaite faire en sorte que si l'utilisateur définit ce paramètre sur un PC, il soit diffusé en itinérance sur les autres PC sur lesquels mon application est installée. La classe ApplicationData possède une propriété RoamingSettings. Pour activer l'itinérance d'un paramètre, il suffit de l'écrire sous forme de valeur dans RoamingSettings.

JS :

Windows.Storage.ApplicationData.current.roamingSettings.values[“ItemsPerPage”] = 10

C# :

Windows.Storage.ApplicationData.Current.RoamingSettings.Values[“ItemsPerPage”] = 10;

C'est tout ! Tous les mécanismes de synchronisation sont gérés par Windows et ce paramètre est alors synchronisé entre tous les PC de l'utilisateur sur lesquels mon application est installée, sans la moindre intervention de ma part. Ce paramètre est généralement présenté à l'utilisateur dans l'icône Paramètres de l'application. Je vous recommande d'activer par défaut l'itinérance pour tous les paramètres d'application. Certains paramètres peuvent être proposés à certaines machines et ne doivent par conséquent pas être enregistrés dans les emplacements itinérants.

Si vous souhaitez écrire un fichier au lieu d'un paramètre, les données d'application offrent également la propriété RoamingFolder, qui fonctionne de la même manière. Lorsque vous décidez d'utiliser un fichier pour diffuser des données en itinérance, pensez à fermer les descripteurs ouverts faisant référence à ce fichier, une fois l'écriture terminée. Les fichiers présentant des descripteurs ouverts ne sont pas diffusés en itinérance.

Prise en compte du quota d'itinérance

Si vous utilisez uniquement des paramètres simples dans votre application, les éléments évoqués ci-dessus vous suffisent. Cependant, qu'en est-il des listes de favoris et des collections ou gros volumes de données ? Quelle peut-être leur taille ? L'itinérance des données d'application est optimisée pour l'itinérance des paramètres et des préférences et n'applique pas de quota de stockage par application, adapté à ces types de données. Le quota vise simplement à éviter de consommer trop de ressources système. L'autonomie et les performances du système font partie des caractéristiques importantes de Windows 8 et la limite imposée empêche tout compromis à ce niveau pour les besoins de ces expériences d'itinérance. Vous pouvez connaître ce quota par le biais de la propriété RoamingStorageQuota de la classe ApplicationData. À l'heure où j'écris ces lignes, le quota est de 100 Ko. Pour rester dans les limites du quota, la meilleure solution consiste à prévoir la consommation de données de votre application au moment de la conception et de faire en sorte qu'elle ne dépasse pas le quota.

Que se passe-t-il en cas de dépassement de la valeur RoamingStorageQuota ? Rien ! Plus précisément, rien n'est transmis en itinérance. Votre application fonctionne parfaitement et peut continuer à lire et à écrire des données dans les emplacements d'itinérance. Cependant, tant que la quantité totale de données itinérantes présentes dans les emplacements d'itinérance est inférieure à la limite RoamingStorageQuota, ces données ne sont pas synchronisées dans le cloud.

L'un des principaux écueils liés aux applications qui ne prévoient pas correctement leur utilisation des données d'itinérance est qu'elles diffusent en itinérance des contenus et non pas des références à ces contenus. Par exemple, si je souhaite diffuser en itinérance un ensemble d'articles d'actualité favoris, je dois diffuser en itinérance les identifiants des articles ou les URL, et non pas l'intégralité des articles. La diffusion de données brutes en itinérance plutôt que des références au contenu disponible provoque très rapidement un dépassement de quota et un gaspillage d'espace. Vous pouvez profiter au mieux de l'itinérance en diffusant les identifiants des contenus en lieu et place des contenus eux-mêmes.

Lorsque vous concevez votre application, il vaut mieux éviter les ensembles de données trop lourds. Une limite doit être appliquée aux ensembles de données ouverts (listes de favoris, par exemple), de façon à ce que votre application ne dépasse pas le quota d'itinérance. Pour reprendre mon exemple de lecteur de flux RSS, supposons maintenant que je souhaite enregistrer la liste des flux RSS, une liste gérée par l'utilisateur. Pour cela, je dois appliquer une limite à un contenu dont la taille n'a normalement pas de limite. Il faut alors procéder à une estimation. Imaginons que je souhaite allouer 20 Ko aux listes de flux RSS. Pour simplifier, je vais estimer la taille d'une URL à 80 octets, ce qui est en principe largement suffisant. Je peux ainsi intégrer 250 URL dans 20 Ko de données. En raccourcissant les URL, je pourrais en intégrer encore plus, mais pour la plupart des applications, 250 URL est plus que suffisant. Il me suffit alors d'imposer cette limite et d'enregistrer ma liste de flux dans un fichier, d'enregistrer ce fichier dans le dossier RoamingFolder et c'est tout !

Création d'une expérience continue d'un PC à l'autre

Vous pouvez également ajouter une autre formidable fonctionnalité d'itinérance à votre application : l'expérience utilisateur continue d'un PC à l'autre. Supposons qu'une personne est chez elle devant son ordinateur de bureau et qu'elle lit ses flux RSS par le biais de mon lecteur. Elle doit s'interrompre pour ne pas rater son bus. En chemin, elle attrape sa tablette Windows 8 et ouvre mon application. Mon but en termes d'expérience utilisateur est de lui permettre de continuer sa lecture exactement là où elle s'est interrompue sur son ordinateur de bureau. Pour offrir une expérience continue, il faut préserver le contexte d'utilisation et le diffuser en itinérance.

Cette fonctionnalité est similaire à l'itinérance des autres paramètres, mais ce scénario diffère de la plupart des paramètres. En effet, l'utilisateur peut naviguer très rapidement au sein des flux, et ce paramètre peut changer bien plus fréquemment que les autres paramètres. Par ailleurs, pour que l'expérience utilisateur puisse être réellement agréable pour l'utilisateur, les données doivent prendre précisément en compte la dernière action réalisée. Pour répondre à ces besoins, nous avons créé un nom de paramètre unique spécialement conçu pour gérer cette expérience : HighPriority. Pour l'utiliser, il vous suffit d'attribuer le nom HighPriority à votre paramètre dans le conteneur racine de RoamingSettings. Il s'utilise comme n'importe quel autre paramètre. Le moteur d'itinérance permet à ce paramètre d'être diffusé en itinérance bien plus rapidement que les autres données itinérantes, pour vous permettre de proposer l'expérience utilisateur attendue.

Pour activer cette fonctionnalité pour mon lecteur de flux, il me suffit de diffuser l'identifiant du flux en itinérance. Lors du lancement de l'application ou de la reprise après suspension, je vérifie l'identifiant et j'accède au flux adéquat. Cet exemple est similaire au paramètre précédent, à la seule différence près que le nom du paramètre est HighPriority.

JS :

Windows.Storage.ApplicationData.current.roamingSettings.values[“HighPriority”] = currentFeedId;

C# :

Windows.Storage.ApplicationData.Current.RoamingSettings.Values[“HighPriority”] = currentFeedId;

À l'instar de l'expérience d'itinérance, Windows s'occupe de la majeure partie du travail et vous n'avez pas à vous en préoccuper. Pour bien utiliser HighPriority, le tout est de savoir quand lire et écrire le paramètre. Généralement, vous devez vérifier HighPriority lors du lancement de l'application et lors de la reprise après suspension, de façon à ce que l'utilisateur puisse accéder aux informations qu'il consultait lorsqu'il a utilisé l'application pour la dernière fois, sur le même PC ou sur un autre appareil. L'écriture du paramètre HighPriority est déclenchée par les actions de l'utilisateur (accès à une nouvelle page, clic sur un lien, etc.).

Le paramètre HighPriority est souvent instantané, mais il peut être ralenti en cas d'écritures rapides. Par conséquent, les écritures inutiles dégradent les performances uniquement dans l'application et n'améliorent pas les expériences d'itinérance. En règle générale, faites en sorte que le paramètre HighPriority représente où se trouve l'utilisateur et ce qu'il fait dans l'application : moment de l'accès aux pages dans l'application, affichage de contenu, etc. Les données de certaines applications changent rapidement. C'est par exemple le cas pour un lecteur vidéo qui suit le compteur de progression de la lecture. Il serait exagéré d'écrire le paramètre HighPriority à chaque fois que le compteur est incrémenté. Aussi, vous pouvez le mettre à jour lorsque l'état de lecture de la vidéo change (Lecture/Pause), lorsque l'utilisateur atteint un point de contrôle ou encore lorsque l'application est suspendue.

Gestion de la cohérence des données

Certaines données sont étroitement liées les unes aux autres et doivent toujours être transmises ensemble en itinérance. L'exemple le plus évident est celui des coordonnées d'un point. Ainsi, il serait absurde de diffuser séparément les coordonnées X et Y d'un point lorsqu'elles sont modifiées, ce qui risquerait de toute façon d'endommager les données et de générer des points non valides. Les unités utilisées pour l'itinérance des données d'application sont les paramètres et les fichiers. Par conséquent, toutes les informations figurant dans un fichier sont toujours diffusées simultanément, et un paramètre constitue en lui-même une unité. Si vous souhaitez diffuser en itinérance plusieurs paramètres simultanément, vous pouvez utiliser une valeur CompositeSettingValue. Ce type de paramètre permet de regrouper plusieurs paramètres dans une valeur unique, qui sera toujours diffusée en itinérance sous forme de bloc.

Le paramètre HighPriority peut également être composite, ce qui vous permet de diffuser en toute sécurité plusieurs éléments de données en itinérance pour représenter l'état actuel de votre application. Par exemple, mon lecteur de flux regroupe les éléments de flux par pages, pour simplifier la lecture. Or, je ne souhaite pas que l'identifiant du flux et la page soient diffusés de façon indépendante en itinérance, car les flux peuvent comporter des nombres de pages différents. En revanche, je souhaite diffuser simultanément en itinérance l'identifiant actuel du flux et la page actuelle au sein de ce flux, sous forme de valeur CompositeSettingValue, afin d'assurer leur cohérence.

JS :

var currentFeed = new Windows.Storage.ApplicationDataCompositeValue();
currentFeed.insert(“CurrentFeedId”, currentFeedId);
currentFeed.insert(“CurrentFeedPage”, currentFeedPage);
Windows.Storage.ApplicationData.current.roamingSettings.values[“HighPriority”] = currentFeed;

C# :

Windows.Storage.ApplicationDataCompositeValue currentFeed = 
new Windows.Storage.ApplicationDataCompositeValue();
currentFeed.Insert(“CurrentFeedId”, currentFeedId);
currentFeed.Insert(“CurrentFeedPage”, currentFeedPage);
Windows.Storage.ApplicationData.Current.RoamingSettings.Values[“HighPriority”] = currentFeed;

Si un composite est utilisé comme paramètre HighPriority, sa taille doit être inférieure à 8 Ko, pour que les avantages du paramètre HighPriority puissent être conservés. Le fait de dépasser 8 Ko ne provoquera pas d'erreur, mais le paramètre sera diffusé en itinérance comme s'il s'agissait d'un paramètre normal.

Prise en compte des changements d'itinérance entrants

Évoquons maintenant le dernier aspect à connaître en matière d'expérience d'itinérance : l'événement DataChanged des données d'application. L'événement DataChanged est tout simplement un événement que vous pouvez signaler chaque fois que les données d'application changent, par exemple pour signaler à une tâche d'arrière-plan que l'utilisateur a modifié un paramètre. Lorsque les données itinérantes du cloud provoquent une modification locale au sein de votre application, Windows signale automatiquement cet événement. Vous pouvez ainsi réagir aux situations où les données d'un autre PC ont été retardées et ont été reçues alors que l'utilisateur avait déjà commencé à utiliser l'application. Vous pouvez utiliser cet événement pour actualiser votre vue sur les données ou réagir face aux changements de paramètres. Vous devez bien comprendre que cette expérience a été optimisée pour les utilisateurs qui utilisent un PC à la fois et passent de l'un à l'autre. Par conséquent, vous ne devez pas utiliser des événements DataChanged comme moyen de communication en temps réel entre des PC.

Prenez part à l'expérience connectée

La mise à disposition d'applications exploitant l'itinérance joue un rôle essentiel pour créer une expérience Windows 8 connectée. Aussi, nous avons créé une plateforme qui facilite la création de ces expériences aussi formidables qu'innovantes. L'itinérance via le cloud est un moyen idéal pour permettre à votre application de se démarquer et satisfaire vos clients en leur proposant une transition pratique et fluide entre leurs PC. Pour plus d'informations sur l'utilisation de la fonctionnalité d'itinérance, consultez les recommandations en matière de données d’application itinérantes. Pensez également à consulter l'exemple ApplicationData, qui offre des exemples des expériences évoquées dans ce billet de blog. Merci d'avoir lu ce billet !

-- Dave Bennett, chef de projet, Windows

  • Loading...
Leave a Comment
  • Please add 4 and 1 and type the answer here:
  • Post