Recommandations en matière de création de formats de données personnalisés

Applies to Windows and Windows Phone

Les utilisateurs sont amenés à partager des informations très diverses lorsqu’ils sont en ligne. Lorsqu’elles sont bien conçues, les applications analysent quels types d’informations sont le plus souvent partagés entre les utilisateurs, puis elles rassemblent ces informations dans un package pour faciliter le traitement des données par les applications cibles. Les informations partagées par les utilisateurs appartiennent majoritairement à l’un des six formats standard pris en charge par Windows. Dans quelques cas cependant, il peut s’avérer utile de mieux cibler le type de données pour améliorer l’expérience utilisateur. Pour cela, votre application peut prendre en charge des formats de données personnalisés.

Exemple

Pour illustrer la façon d’appréhender la création d’un format personnalisé, prenons l’exemple suivant.

Un développeur de l’entreprise fictive Fabrikam crée une application qui partage des fichiers stockés en ligne. Une option consisterait à utiliser le format StorageItems géré par flux, mais cette méthode s’avérerait chronophage et inefficace car l’application cible finirait par télécharger les fichiers localement pour les lire. Le développeur décide plutôt de créer un format personnalisé pour ces types de fichiers.

Pour commencer, le développeur s’attache à la définition du nouveau format. Dans ce cas, il s’agit d’une collection d’un type de fichier donné (document, image, etc.) qui est stockée en ligne. Le développeur nomme le format « WebFileItems » pour indiquer que les fichiers sont stockés sur le Web et pas sur l’ordinateur local.

Ensuite, il doit choisir les détails précis du format et prendre en compte les éléments suivants :

  • Le format doit être composé d’un objet IPropertyValue contenant un objet InspectableArray qui représente les URI (Uniform Resource Identifier).
  • Le format doit contenir au moins 1 élément, mais le nombre d’éléments qu’il peut contenir est illimité.
  • Tous les URI valides sont autorisés.
  • Les URI qui ne sont pas accessibles en dehors des limites de l’application source (tels que les URI authentifiés) ne sont pas recommandés.

Une fois qu’il a clairement identifié ces informations, le développeur peut commencer à créer et utiliser un format personnalisé.

Est-ce que mon application doit utiliser des formats personnalisés ?

La fonctionnalité de partage de Windows 8 prend en charge les six formats de données standard suivants :

  • text
  • HTML
  • bitmap
  • StorageItems
  • URI
  • RTF

Grâce à la souplesse de ces formats, votre application peut facilement et rapidement prendre en charge le partage de contenu et la réception de contenu partagé. Ces formats présentent l’inconvénient de ne pas fournir toujours de description riche des données pour l’application cible. La chaîne suivante, qui représente une adresse postale, illustre bien ce problème :

1234 Main Street, New York, NY 98208

L’application peut partager cette chaîne en utilisant la méthode DataPackage.setText. Avec cette méthode, l’application qui reçoit cette chaîne de texte ne peut pas déterminer précisément à quoi elle correspond, ce qui restreint les actions possibles sur ces données. Avec un format de données personnalisé, l’application source peut définir les données partagées en tant qu’endroit à l’aide du format http://schema.org/Place. L’application cible dispose ainsi d’informations supplémentaires lui permettant de traiter les données de la manière attendue par l’utilisateur. L’utilisation de formats de schémas existants permet à votre application de puiser dans une base de données plus importante de formats définis.

Les formats personnalisés vous permettent également d’offrir des méthodes de partage de données plus performantes. Imaginons, par exemple, qu’un utilisateur qui dispose d’une collection de photos stockée sur Microsoft OneDrive souhaite en partager certaines sur un réseau social. Ce scénario est délicat à implémenter à l’aide des formats standard, pour les raisons suivantes :

  • Vous ne pouvez utiliser le format URI que pour partager un élément à la fois.
  • OneDrive partage les collections au format StorageItems géré par flux. L’utilisation du format StorageItems dans ce scénario nécessite que votre application télécharge chaque image, puis la partage.
  • Les formats Text et HTML vous permettent de fournir la liste des liens, mais la signification sera perdue, c’est-à-dire que l’application réceptrice ne saura pas que ces liens représentent les images que l’utilisateur souhaite partager.

L’utilisation d’un format de schéma existant ou personnalisé pour partager ces images offre les deux avantages principaux suivants :

  • Votre application peut partager les images plus rapidement, car vous pouvez créer une collection d’URI, plutôt que de télécharger toutes les images en local.
  • L’application réceptrice qui comprendra que ces URI représentent des images pourra les traiter de manière appropriée.

Pratiques conseillées et déconseillées

Définition d’un format personnalisé

Si vous choisissez de définir un format personnalisé pour votre application, tenez compte des quelques points suivants :

  • Vérifiez au préalable qu’aucun des formats de données standard ne convient pour ne pas créer inutilement un format personnalisé. Vérifiez s’il existe un format existant sur http://www.schema.org qui serait adapté à votre scénario. Il est plus probable qu’une autre application utiliserait un format existant plutôt que votre format personnalisé, ce qui signifie qu’un public plus vaste pourrait réaliser les scénarios intégraux que vous voulez.
  • Réfléchissez aux expériences que vous souhaitez prendre en charge. Pour cela, il est important de répertorier les actions susceptibles d’être demandées par les utilisateurs et de déterminer les formats de données les plus adaptés à ces actions.
  • Rendez la définition de votre format personnalisé accessible aux autres développeurs d’applications.
  • Choisissez un nom de format pertinent par rapport au contenu du format. Par exemple, UriCollection indique que n’importe quel URI est valide, alors que WebImageCollection indique que le format contient uniquement des URI pointant vers des images en ligne.
  • Réfléchissez à la signification précise du format. Ayez une idée claire de ce que le format représente et de la façon dont il doit être utilisé.
  • Vérifiez la structure du format. Déterminez si le format prend en charge les éléments multiples ou la sérialisation, et répertoriez les limitations du format.
  • Après avoir publié votre format personnalisé, ne le modifiez plus. Traitez ce format comme une API : des éléments peuvent être ajoutés ou déconseillés, mais la compatibilité descendante et la prise en charge à long terme sont des critères essentiels.
  • N’utilisez pas de combinaisons de formats. Par exemple, une application qui détecte un format donné ne comprendra pas qu’elle doit rechercher un deuxième format. Chaque format doit être autonome.

Ajout de formats personnalisés à votre application

Une fois que vous avez défini un format personnalisé, suivez ces recommandations quand vous l’ajoutez à votre application :

  • Testez le format avec d’autres applications. Vérifiez que les données sont traitées correctement entre l’application source et l’application cible.
  • Conformez-vous à l’objectif initial du format. N’utilisez pas le format autrement que de la façon prévue.
  • Si vous développez une application source, fournissez également au moins un format standard. Ainsi, les utilisateurs pourront partager des données avec des applications qui ne prennent pas en charge le format personnalisé. Même si cette solution n’offre pas toujours une expérience utilisateur optimale, elle est préférable à une situation où les utilisateurs n’auraient pas la possibilité de partager leurs données avec les applications de leur choix. Documentez également votre format en ligne pour que les autres applications connaissent son existence et puissent l’adopter.
  • Si vous développez une application cible, prévoyez la prise en charge d’au moins un format standard. De cette manière, votre application pourra recevoir des données d’applications sources qui n’utilisent pas le format personnalisé de votre choix.
  • Si vous souhaitez accepter un format personnalisé spécifique provenant d’une autre application, et particulièrement d’une autre société, vérifiez qu’il est documenté publiquement en ligne. Les formats non documentés sont plus susceptibles de changer sans préavis, engendrant des problèmes d’incohérences voire de rupture de votre application.

Indications d’utilisation supplémentaires

Choix d’un type de données

L’un des choix les plus importants à faire lorsque vous définissez un format personnalisé concerne le type de données WinRT à utiliser pour transférer le format entre les applications source et cible. La classe DataPackage prend en charge plusieurs types de données pour un format personnalisé :

Lorsque vous définissez un format, sélectionnez le type de données approprié. Il est essentiel que tous les utilisateurs et destinataires du format choisi utilisent le même type de données, quelles que soient les options possibles. Sinon, une erreur peut se produire en raison de la présence de types de données non concordants dans les applications cibles.

Si vous choisissez une chaîne comme type de données pour votre format, vous pouvez la récupérer sur l’application cible à l’aide de la forme GetTextAsync(formatId) de la fonction GetTextAsync. Cette fonction vérifie automatiquement le type de données. Sinon, vous devez utiliser la méthode GetDataAsync, ce qui vous oblige à prendre des mesures pour éviter les problèmes de non-correspondance des types de données. Par exemple, si une application source fournit un seul URI, mais que la cible essaie de la récupérer en tant que collection d’URI, une erreur de non-correspondance se produit. Pour éviter ce type de conflits, ajoutez un code similaire au code suivant :

Remplissage de l’objet DataPackage


var uris = new Array();
uris[0] = new Windows.Foundation.Uri("http://www.msn.com");
uris[1] = new Windows.Foundation.Uri("http://www.microsoft.com");
var dp = new Windows.ApplicationModel.DataTransfer.DataPackage();
dp.setData("UriCollection", uris);


Récupération des données


if (dpView.contains("UriCollection")) {
    dpView.getDataAsync("UriCollection").done(function(uris) {
        // Array.isArray doesn’t work – uris is projected from InspectableArray
        if (uris.toString() === "[object ObjectArray]") {
            var validUriArray = true;
            for (var i = 0; (true === validUriArray) && (i < uris.length); i++) {
                validUriArray = (uris[i] instanceof Windows.Foundation.Uri);
            }
            if (validUriArray) {
                // Type validated data 
            }
        }
    }
}


Rubriques associées

Pour les développeurs (HTML)
Sélection des formats de données pour le partage
Quickstart: Sharing content
Quickstart: Receiving shared content
Pour les développeurs (XAML)
Sélection des formats de données pour le partage
Quickstart: Sharing content
Réception de contenu partagé
Exemples
Exemple de partage de contenu source entre applications
Exemple de partage de contenu cible entre applications

 

 

Afficher:
© 2014 Microsoft