Directrices para crear formatos de datos personalizados

Applies to Windows and Windows Phone

Los usuarios comparten diversos tipos de información cuando están en línea. Las aplicaciones eficaces se toman tiempo para analizar los tipos de información que es más probable que los usuarios compartan con otros y empaquetan esa información para que las aplicaciones receptoras la puedan procesar correctamente. En muchos casos, la información que los usuarios quieren compartir entra en uno de los seis formatos estándar admitidos por Windows. Sin embargo, hay algunos casos en los que tener un tipo de datos más específico puede ayudar a crear una mejor experiencia del usuario. Para estas situaciones, tu aplicación puede admitir varios formatos de datos.

Ejemplo

Para ilustrar mejor la manera de concebir la creación de un formato personalizado, considera el ejemplo siguiente.

En la empresa ficticia, Fabrikam, un desarrollador escribe una aplicación que comparte archivos almacenados en línea. Una opción sería usar StorageItems respaldados por secuencias, pero eso llevaría mucho tiempo y resultaría poco eficaz, porque la aplicación de destino terminaría descargando los archivos localmente para leerlos. En lugar de ello, el desarrollador decide crear un formato personalizado para usar con estos tipos de archivo.

Primero, el desarrollador considera la definición del nuevo formato. En este caso, es una colección de cualquier tipo de archivo (documento, imagen, etc.) que se almacena en línea. Debido a que los archivos se encuentran en Internet y no en el equipo local, el desarrollador decide asignarle el nombre WebFileItems al formato.

Después, el desarrollador debe decidir los detalles específicos del formato, y decide lo siguiente:

  • El formato debe constar de un IPropertyValue que contenga una InspectableArray que represente los identificadores uniformes de recursos (URI).
  • El formato debe contener al menos un elemento, pero no hay límite con respecto a la cantidad de elementos que puede contener.
  • Se permite cualquier URI válido.
  • No se recomiendan los URI que no sean accesibles fuera de los límites de la aplicación de origen (como los URI autenticados).

Con esta información establecida, el desarrollador ahora cuenta con información suficiente para crear y usar un formato personalizado.

¿Debo usar formatos personalizados en la aplicación?

La característica de uso compartido de Windows 8 admite seis formatos de datos estándar:

  • Texto
  • HTML
  • Mapa de bits
  • StorageItems
  • URI
  • RTF

Estos formatos son muy versátiles, lo que hace que sea más fácil para tu aplicación admitir rápidamente uso compartido de contenido y recepción de contenido compartido. La desventaja de estos formatos es que no ofrecen mucho una descripción detallada de los datos a la aplicación receptora. Para ilustrar esto, observa la cadena siguiente, que representa una dirección postal:

1234 Main Street, New York, NY 98208

Una aplicación puede compartir esta cadena mediante DataPackage.setText. Sin embargo, dado que la aplicación que recibe la cadena de texto no sabe exactamente qué representa la cadena, es limitada en cuanto a lo que puede hacer con los datos. Con un formato de datos personalizado, la aplicación de origen puede definir los datos que se comparten como un "lugar", usando el formato http://schema.org/Place. Esto proporciona a la aplicación receptora algo de información adicional que puede usar para procesar la información del modo que espera el usuario. El uso de los formatos de esquema existentes permite a la aplicación enlazar con una base de datos mayor de formatos definidos.

Además, los formatos personalizados pueden proporcionar maneras más eficaces de compartir datos. Por ejemplo, un usuario tiene una colección de fotos almacenada en Microsoft OneDrive y decide compartirlas en una red social. Este escenario es difícil de implementar usando los formatos estándar, por las razones siguientes:

  • Solamente puedes usar el formato URI para compartir un elemento cada vez.
  • OneDrive comparte las colecciones como StorageItems respaldados por secuencias. Para usar StorageItems en este escenario, sería necesario que tu aplicación descargue cada imagen y después las comparta.
  • El texto y el contenido HTML te permiten proporcionar una lista de vínculos, pero el significado de esos vínculos se pierde; la aplicación receptora no sabe que estos vínculos representan las imágenes que el usuario quiere compartir.

El uso de un formato de esquema existente o un formato personalizado para compartir estas imágenes ofrece dos ventajas principales:

  • Tu aplicación puede compartir las imágenes más rápidamente, porque puedes crear una colección de URI en lugar de descargar todas las imágenes a una ubicación local.
  • La aplicación receptora entiende que los URI representan estas imágenes y puede procesarlas de forma correspondiente.

Qué hacer y qué no hacer

Definición de un formato personalizado

Si decides que tu aplicación se puede beneficiar de la definición de un formato personalizado, hay algunas cosas que debes tener en cuenta:

  • Asegúrate de que comprendes los formatos de datos estándar para no crear un formato personalizado si no es necesario. Debes comprobar si existe un formato en http://www.schema.org apropiado para tu escenario. Es más probable que otra aplicación use un formato existente en lugar de tu formato personalizado, lo que significa que un público mayor podría lograr los escenarios completos que deseas.
  • Ten en cuenta las experiencias que quieres posibilitar. Es importante que pienses en las acciones que los usuarios querrán realizar y en los formatos de datos más adecuados para esas acciones.
  • Haz que la definición del formato personalizado esté disponible para los demás desarrolladores de aplicaciones.
  • Al asignarle un nombre a un formato, asegúrate de que el nombre coincida con el contenido del formato. Por ejemplo, UriCollection indica que cualquier URI es válido, mientras que WebImageCollection indica que contiene solo URI que apuntan a imágenes en línea.
  • Considera detenidamente el significado del formato. Ten una clara comprensión de lo que representa el formato y de la manera en que debe usarse.
  • Revisa la estructura del formato. Piensa detenidamente en si el formato admite varios elementos o serialización y en las limitaciones que presenta.
  • No cambies el formato personalizado después de publicarlo. Considéralo como una API: puedes agregar o dejar de usar elementos, pero es importante que tengas en cuenta la compatibilidad con versiones anteriores y la compatibilidad a largo plazo.
  • No confíes en combinaciones de formatos. Por ejemplo, no esperes que una aplicación entienda que, si ve un formato, también debe buscar un formato secundario. Cada formato debe ser autocontenido.

Adición de formatos personalizados a tu aplicación

Después de definir un formato personalizado, sigue estas recomendaciones para agregar el formato a tu aplicación:

  • Prueba el formato con otras aplicaciones. Asegúrate de que los datos se procesen correctamente desde la aplicación de origen hacia la aplicación de destino.
  • No te desvíes del propósito original del formato. No lo uses de maneras no previstas.
  • Si vas a escribir una aplicación de origen, proporciona al menos un formato estándar también. Esto garantiza que los usuarios puedan compartir datos con aplicaciones que no admiten el formato personalizado. Es posible que la experiencia no sea la ideal para el usuario, pero esto es mejor que no permitirle compartir datos con las aplicaciones que quiere. También debes documentar tu formato en línea para que otras aplicaciones sepan cómo adoptarlo.
  • Si vas a escribir una aplicación de destino, considera la posibilidad de admitir al menos un formato estándar. De este modo, tu aplicación puede recibir datos de aplicaciones de origen, aunque no usen el formato personalizado de tu preferencia.
  • Si quieres aceptar un formato personalizado específico de otra aplicación, especialmente de una compañía diferente, debes comprobar bien si está documentada en línea de forma pública. Es más probable que los formatos no documentados cambien sin previo aviso, lo que podría crear incoherencias o inhabilitar tu aplicación.

Instrucciones de uso adicionales

Elección de un tipo de datos

Una de las decisiones más importantes que deberás tomar para definir un formato personalizado es el tipo de datos de WinRT que se usa para transferir datos entre aplicaciones de origen y de destino. La clase DataPackage admite varios tipos de datos para un formato personalizado:

Al definir un formato, selecciona el tipo adecuado para los datos. Es muy importante que todos los consumidores y destinatarios de este formato usen los mismos tipos de datos, aunque existan opciones diferentes. De lo contrario, se pueden producir errores inesperados de falta de coincidencia en el tipo de datos en las aplicaciones de destino.

Si eliges una cadena como tipo de datos para el formato, puedes recuperarla en el destino usando el formulario GetTextAsync(formatId) o la función GetTextAsync. Esta función realiza la comprobación del tipo de datos por ti. De lo contrario, tienes que usar GetDataAsync, lo que significa que debes aplicar una protección contra posibles errores de falta de coincidencia en los tipos de datos. Por ejemplo, si una aplicación de origen proporciona un solo URI y la aplicación de destino intenta recuperarlo como una colección de URI, se produce una falta de coincidencia. Para ayudar a prevenir estos conflictos, puedes agregar código similar a este:

Relleno de 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);


Recuperación de datos


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 
            }
        }
    }
}


Temas relacionados

Para desarrolladores (HTML)
Elección de formatos de datos para uso compartido
Quickstart: Sharing content
Quickstart: Receiving shared content
Para desarrolladores (XAML)
Elección de formatos de datos para uso compartido
Quickstart: Sharing content
Recepción de contenido compartido
Muestras
Muestra de una aplicación de origen de contenido compartido
Muestra de una aplicación de destino de contenido compartido

 

 

Mostrar:
© 2014 Microsoft