Nota
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
Opciones de acceso y almacenamiento de datos en las aplicaciones de la Tienda Windows
La administración de los datos es una parte fundamental en el desarrollo de las aplicaciones. Ya sea en las aplicaciones de juegos, noticias, viaje o moda: siempre se trata de los datos. Las aplicaciones modernas frecuentemente deben administrar datos que se encuentran repartidos en diferentes ubicaciones dispares, en innumerables formatos. Examinaré las diferentes opciones de almacenamiento de datos y API de acceso a datos disponibles para la creación de aplicaciones de la Tienda Windows en todos los lenguajes, además de estrategias de administración de datos para los contenidos y su configuración.
Factores en la administración y almacenamiento de datos
Como desarrolladores, debemos determinar los requisitos de nuestra aplicación antes de iniciar el proyecto, ya que cualquier cambio en la infraestructura subyacente requiere de modificaciones significativas . A veces tenemos un origen de datos existente, en cuyo caso la decisión ya fue tomada, pero en los proyectos que parten de cero debemos reflexionar sobre dónde vamos a almacenar los datos. Las dos opciones posibles son el dispositivo y un lugar remoto:
- Almacenamiento local: estos datos generalmente se encuentran en un archivo o base de datos local, pero en Windows 8 también podemos tratar a otras aplicaciones como orígenes de datos, al emplear el Selector de archivos integrado o contratos. En el caso de las aplicaciones en JavaScript, también disponemos de Web Storage y de la API de base de datos indizada (IndexedDB) como orígenes de datos locales.
- Almacenamiento remoto: estos datos se podrían encontrar en la nube en Windows Azure SkyDrive o cualquier extremo HTTP remoto que entregue datos en formato JSON o XML, incluso las API públicas como Facebook o Flickr.
El tamaño de los datos frecuentemente determina si los datos se almacenan en forma local o remota; sin embargo, la mayoría de las aplicaciones remotas emplearán datos de ambos orígenes. Esto se debe a que los dispositivos más pequeños y móviles como tabletas táctiles, tabletas y teléfonos se han convertido en la norma y por lo general no cuentan con mucho espacio de almacenamiento. A pesar de esto, requieren de datos para funcionar correctamente cuando están desconectados. Surface, por ejemplo, al igual que muchos otros dispositivos portátiles, está disponible en modelos con 32 GB y 64 GB. Los datos sencillos en formato de texto (como JSON) generalmente no son grandes, pero las bases de datos relacionales y los datos multimedia (como imágenes audio y vídeo) pueden llenar el dispositivo rápidamente.
Echemos una mirada a las diferentes opciones locales y remotas para almacenar datos de contenido de aplicaciones.
Web Storage
Podría parecer como si Web Storage (bit.ly/lml0Ul) no fuera más que un almacenamiento en la Web solamente, pero no es así. El estándar Web Storage de HTML5 es una forma excelente de almacenar los datos de las aplicaciones en el cliente, en forma local. Tanto las aplicaciones para la Tienda Windows como las páginas HTML simples de toda la vida son compatibles con Web Storage. No hace falta configurar ninguna base de datos y no hay que copiar archivos, ya que Web Storage es una base de datos que reside en la memoria.
JavaScript puede tener acceso a Web Storage a través de una de las siguientes propiedades del objeto window:
- localStorage: datos locales que se conservan una vez que la aplicación finaliza y están disponibles para las instancias futuras de la aplicación.
- sessionStorage: también son datos locales, pero sessionStorage se destruye una vez que la aplicación de la Tienda Windows se deja de ejecutar.
En Web Storage podemos almacenar desde tipos sencillos hasta objetos complejos, al adjuntar propiedades dinámicas a las variables sessionStorage y localStorage. Las propiedades dinámicas son pares clave/valor con una sintaxis similar a:
sessionStorage.lastPage = 5;
WinJS.xhr({ url: "data/data.json" }).then(function (xhr) {
localStorage.data = xhr.responseText;
};
La propiedad lastPage existe hasta que la aplicación finaliza, ya que forma parte de sessionStorage, mientras que la propiedad data de localStorage se conserva más allá de la duración de la aplicación.
Gracias a la posibilidad de persistir datos localmente entre las sesiones de una aplicación, Web Storage es una excelente opción para las situaciones sin conexión. Los datos pequeños también se prestan mejor para trabajar sin conexión. Como los datos en formato JSON son compactos, resulta fácil almacenar conjuntos de datos completos en JSON dentro del espacio de 5 MB disponible en Web Storage y tener espacio de sobra para algunos datos multimedia.
Como Web Storage es un estándar HTML5, solo está disponible en los proyectos de la Tienda Windows que se crean con JavaScript.
IndexedDB
Otro estándar de la familia HTML5 es IndexedDB (bit.ly/TT3btM), que es un almacén de datos local persistente para conjuntos de datos grandes con funciones de búsqueda. Como componente de HTML5, podemos usar IndexedDB en las aplicaciones web cliente para exploradores y en las aplicaciones para la Tienda Windows. IndexedDB almacena los elementos en una base de datos de objetos y es extremadamente flexible, ya que permite almacenar cualquier tipo de datos, desde texto hasta objetos binarios grandes (BLOB). Por ejemplo, como los archivos multimedia tienden a ser grandes, IndexedDB resulta ser una buena opción para almacenar audio y vídeo.
Como IndexedDB es una base de datos de objetos, no emplea instrucciones SQL, así que el acceso se realiza mediante una sintaxis con un estilo orientado a objetos. La interacción con un almacén de datos IndexedDB se realiza mediante transacciones y cursores, como se muestra aquí:
var dataStore = "Datastore";
var trn = db.transaction(dataStore, IDBTransaction.READ_ONLY);
var store = trn.objectStore(dataStore);
trans.oncomplete = function(evt) { // transaction complete };
var request = store.openCursor();
request.onsuccess = function(evt) {
var cursor = evt.openCursor();
};
request.onerror = function(error) { // error handling };
Como IndexedDB se especializa en datos realmente grandes, no es eficiente para almacenar elementos pequeños y Web Storage es una opción mucho mejor para datos locales con tamaños en el orden de los bytes. IndexedDB también se presta bien para datos de contenidos, pero no así para datos de configuración de aplicaciones.
SQLite
SQLite (bit.ly/65FUBZ) es una base de datos transaccional autónoma basada en archivos que no requiere de configuración y no necesita de ningún administrador de datos para su mantenimiento. Podemos usar SQLite con cualquier lenguaje de Windows en tiempo de ejecución (WinRT) y está disponible como extensión para Visual Studio. Aunque SQLite funciona bien en las aplicaciones escritas en JavaScript, debemos descargar el contenedor de SQLite3 para WinRT (bit.ly/J4zzPN) en GitHub antes de usarlo.
Es natural que los desarrolladores con experiencia en ASP.NET y Windows Forms se sientan atraídos por las bases de datos relacionales, pero cuando escribimos aplicaciones modernas, los sistemas de administración de bases de datos relacionales (RDBMS) no son siempre la mejor opción, debido a los problemas de espacio en los dispositivos móviles y los diferentes tipos de formatos de datos, en especial los multimedia. Como SQLite es una base de datos relacional, resulta conveniente para aquellas aplicaciones que requieren de comportamientos relacionales y transaccionales. Esto significa que SQLite es excelente para las aplicaciones de línea de negocio (LOB) y otras aplicaciones de entrada de datos, y también sirve como repositorio para los datos locales sin conexión que originalmente se obtuvieron en un origen en línea.
Si la base de datos SQLite se vuelve demasiado grande para los dispositivos portátiles, podemos trasladarla a un servidor o una ubicación en nube. El código no cambiará mucho, ya que la biblioteca de SQLite3 emplea una conexión tradicional y objetos de creación, lectura, actualización y eliminación (CRUD) similares al siguiente código:
// C# code that opens an async connection.
var path =
Windows.Storage.ApplicationData.Current.LocalFolder.Path + @"\data.db";
var db = new SQLiteAsyncConnection(path);
// JavaScript code that opens an async connection.
var dbPath =
Windows.Storage.ApplicationData.current.localFolder.path + '\\data.db;
SQLite3JS.openAsync(dbPath).then(function (db) {
// Code to process data.
});
Como puede apreciar, SQLite se usa igual que cualquier otra base de datos SQL. Los límites en las bases de datos SQLite pueden alcanzar hasta 140 TB. Tenga en cuenta que cuando las cantidades de datos son extremadamente grandes, frecuentemente conviene usar una administración de base de datos profesional para lograr la mejor integridad de datos, rendimiento y seguridad posibles. La mayoría de los administradores y desarrolladores de bases de datos que trabajan con bases de datos relacionales prefieren una herramienta con interfaz gráfica de usuario para crear y administrar los objetos de la base de datos o ejecutar consultas ad hoc en los datos, y la utilidad de administración Sqliteman (bit.ly/9LrB1o) resulta ideal para todas las operaciones básicas de SQLite.
Si va a portar aplicaciones de escritorio existentes para Windows escritas en Windows Forms, Windows Presentation Foundation (WPF) o Silverlight, es posible que ya esté usando SQL Server Compact (SQL CE). En este caso, puede migrar las bases de datos SQL CE a SQLite con la utilidad ExportSqlCE (bit.ly/dwVaR3) y luego usar Sqliteman para administrarlas.
Archivos como datos y la API de archivo
¿Por qué molestarse con una base de datos, especialmente si los usuarios de la aplicación quieren quedarse con los archivos que ya tienen? Esto es especialmente cierto en el caso de las fotos y los documentos. La API de archivo va más allá de entregar simplemente un navegador para los directorios y archivos; permite que el usuario elija una aplicación como la ubicación de un archivo. Esto significa que las aplicaciones pueden hablar entre ellas e intercambiar datos. Un Selector de archivos para abrir puede interactuar con Bing, aplicaciones de cámara o fotos, aparte de los directorios y las ubicaciones con nombres corrientes como, por ejemplo, Mis documentos, Vídeos y Música. Esta capacidad de compartir datos en forma tan fácil entre las aplicaciones, los servicios y los archivos personales es una característica de primera categoría de Windows.
Muchos sistemas operativos tienen un mecanismo para registrar los tipos de archivos empleados por las aplicaciones junto con la posibilidad de iniciar estas aplicaciones cuando un usuario interactúa con un icono en el sistema operativo. En Windows esto se llama una asociación de archivos. Windows 8 extiende este concepto, al permitir que las aplicaciones se comuniquen entre sí a través de una función que abarca todo el sistema, llamada contratos. Una forma de implementar un contrato es mediante un Selector de archivos. Observe que el siguiente código es similar a las API de Cuadro de diálogo de archivos de las aplicaciones de escritorio o las versiones previas de Windows (nota: por motivos de espacio se omitió parte del código del ejemplo; para ver un análisis más completo de la clase FileOpenPicker, consulte bit.ly/UztmDv):
fileOpen: function () {
var openPicker = new Windows.Storage.Pickers.FileOpenPicker();
openPicker.viewMode = Windows.Storage.Pickers.PickerViewMode.thumbnail;
openPicker.suggestedStartLocation =
Windows.Storage.Pickers.PickerLocationId.picturesLibrary;
openPicker.fileTypeFilter.replaceAll([".png", ".jpg", ".jpeg"]);
openPicker.pickSingleFileAsync().done(function (file) {
// ...
});
}
Al elegir una aplicación del selector de Windows 8 se inicia esa aplicación. Por ejemplo, si el usuario selecciona Bing, entonces el selector iniciará la aplicación Bing y luego devolverá la selección de la imagen del usuario a nuestra aplicación.
Ahora que ya vimos las opciones locales, echemos una mirada a las opciones de datos remotos.
Servicios web y ASP.NET Web API
La mayoría de los desarrolladores están familiarizados con el consumo y la modificación de datos con los servicios web XML, ya que estos se remontan a los tiempos de Microsoft .NET Framework 1.x. La principal ventaja de los servicios web es que los datos quedan en una ubicación central remota y las aplicaciones de diferentes dispositivos pueden tener acceso a los datos en cualquier momento, mientras estén conectados. El acceso a la base de datos subyacente se canaliza a través de un conjunto de extremos HTTP que intercambia datos en formato JSON o XML. Muchas API públicas como Twitter o Flickr exponen datos en JSON y XML que se pueden consumir en las aplicaciones de la Tienda Windows.
Los servicios web se presentan en diferentes variantes:
- Servicios ASMX: emplean ASP.NET tradicional para entregar datos a través de HTTP.
- Servicios Windows Communication Foundation (WCF) y de aplicación de Internet enriquecida (RIA): una forma basada en mensajes para enviar datos entre extremos HTTP.
- OData: Open Data Protocol, otra API para transportar datos por HTTP.
- ASP.NET Web API: un nuevo marco ASP.NET MVC 4 que simplifica la creación de servicios HTTP que cumplan con los principios de REST y que entreguen datos JSON o XML a las aplicaciones o sitios web.
Si crea servicios back-end a partir de cero, entonces ASP.NET Web API simplifica el proceso de desarrollo, ya que facilita la creación de servicios en forma coherente y compatible con REST, listos para ser consumidos por las aplicaciones.
Independientemente del servicio back-end, si la transmisión se realiza por HTTP, podemos usar los objetos HttpWebRequest y HttpWebResponse para comunicarnos con un servicio web mediante C#. En las aplicaciones escritas en JavaScript, un contenedor XMLHttpRequest de WinJS se presta para las operaciones asincrónicas, parecido a esto:
WinJS.xhr({ url: "data.json" }).then(function (xhr) {
var items = JSON.parse(xhr.responseText);
items.forEach(function (item) {
list.push(item);
})
});
Por lo general, el espacio de almacenamiento no es un problema en los servicios web, ya que un servicio web es simplemente el software que transporta los datos entre los extremos. Esto significa que la base de datos subyacente puede residir en cualquier lugar, por ejemplo en un servidor remoto, host de web o instancia de Windows Azure.
Podemos hospedar cualquiera de los servicios web mencionados como, por ejemplo, una instancia de ASP.NET Web API o servicio WCF en Windows Azure, junto con los datos mismos.
SkyDrive
No olvide que SkyDrive (bit.ly/HYB7iw) no solo es una opción más para almacenar datos, sino que es una opción excelente. Debe pensar en SkyDrive como una opción de no-almacenamiento. Los usuarios pueden elegir SkyDrive como una ubicación en la nube y tener acceso a los documentos a través del selector Abrir archivo o Guardar. Permitir que los usuarios guarden archivos en SkyDrive significa cero preocupaciones para la administración y, con 7 GB de espacio por usuario, hay espacio suficiente. Los usuarios de SkyDrive también pueden adquirir espacio adicional.
la API de Live (bit.ly/mPNb03) contiene un conjunto de API de SkyDrive completo compatibles con REST para leer y escribir en SkyDrive. Una llamada a SkyDrive para recuperar el listado de los elementos compartidos tiene el siguiente aspecto:
GET https://apis.live.netv5.0/me/skydrive/shared?access_token=ACCESS_TOKEN
El espacio de nombres Microsoft.Live permite a los desarrolladores en C# tener acceso a las API de Live y SkyDrive, mientras que los desarrolladores en JavaScript pueden realizar llamadas compatibles con REST con los verbos HTTP POST y PUT. SkyDrive no se recomienda para los datos de configuración de las aplicaciones.
Servicios móviles de Windows Azure
Servicios móviles de Windows Azure es una excelente opción para los desarrolladores de aplicaciones para varias plataformas. Con tecnología Windows Azure, esta opción ofrece más que solo un almacenamiento escalable: ofrece notificaciones de inserción, administración de la lógica de negocios, una API de autenticación y un SDK completo. Además de estas características, cuenta con una herramienta de administración basada en web fácil de usar.
El SDK de los Servicios móviles se integra con la Tienda Windows, las aplicaciones para Windows Phone 8, iOS y Android. Es compatible con todas las principales plataformas, y el SDK de los Servicios móviles nos permite crear en cosa de minutos un prototipo funcional y listo para entregar datos a aplicaciones multiplataforma en poquísimo tiempo.
Entre los diferentes elementos del SDK, podemos usar el objeto query para realizar consultas de datos en las tablas, similar a esto:
var query = table.orderBy('column').read({ success: function(results) { ... }});
Como puede apreciar, el código es más o menos el mismo que con cualquier otra API, así que la curva de aprendizaje es la misma que con las otras opciones que vimos en este artículo. Puede tener acceso al SDK y a los Servicios móviles con cualquier lenguaje de la Tienda Windows.
Opciones de administración y almacenamiento de datos de aplicaciones
Todas las opciones de almacenamiento y acceso a datos que vimos hasta aquí sirven para almacenar contenidos, pero como desarrolladores también debemos encargarnos de los datos de configuración de la aplicación. Estos son los metadatos que describen la aplicación o las funciones del dispositivo, no los datos del usuario. Las aplicaciones modernas se valen tanto de datos de aplicación persistentes (como preferencias de usuario) y metadatos temporales (como la última posición de desplazamiento del usuario o los principales términos de búsqueda). Estas conveniencias pequeñas y eficaces garantizan la mejor experiencia posible para el usuario, así que es importante incorporarlas en las aplicaciones.
Mientras que algunos de estos datos pertenecen al dispositivo, tenga en cuenta el hecho que muchas aplicaciones funcionan en diferentes plataformas y dispositivos, así que muchas veces conviene centralizar y sincronizar los datos de la aplicación en Windows Azure con los datos de contenidos.
En la clase con el nombre descriptivo ApplicationData en el espacio de nombres Windows.Storage, existe un conjunto de API específicas para la administración de los datos de aplicaciones, y el código se parece a:
var localSettings = Windows.Storage.ApplicationData.current.localSettings;
var roamingSettings = Windows.Storage.ApplicationData.current.roamingSettings;
Puede almacenar objetos simples o complejos en las propiedades localSettings o roamingSettings.
Las configuraciones locales y de roaming son la forma preferida de trabajar con los datos de configuración. Las tecnologías como IndexedDB, archivos o SkyDrive generalmente no son opciones buenas para los datos de configuración de las aplicaciones, y el uso de SQLite solo conviene cuando la aplicación ya lo emplea para almacenar contenidos. También debe evaluar qué ocurre cuando la aplicación está sin conexión o desconectada de Internet. En otras palabras, debe almacenar en caché algunos datos, pero sin consumir demasiado espacio en disco.
Contenidos y configuración
En resumidas cuentas, para implementar una arquitectura de datos adecuada, no debería depender del espacio limitado de los dispositivos portátiles, así que hospedar los datos en la nube generalmente es una apuesta segura. Pero si tiene una base de datos heredada, puede estar obligado a usarla. Las aplicaciones para la Tienda Windows cuentan con varios tipos de almacenamiento estructurado y BLOB para el contenido y las configuraciones.
Si está creando una aplicación para la Tienda Windows y necesita ayuda para elegir la estrategia de acceso a datos, le recomiendo que eche una mirada al programa Generation App (bit.ly/W8GenAppDev). Generation App lo guía a través del proceso de generación de una aplicación para la Tienda Windows (o para Windows Phone) en 30 días y ofrece consultas y asistencia técnica y de diseño en forma gratuita, junto con consejos y recursos exclusivos.
Rachel Appel es evangelizadora de desarrollo en Microsoft en la ciudad de Nueva York. Puede ubicarla en su sitio web en rachelappel.com o por correo electrónico en rachel.appel@microsoft.com. También puede seguir sus últimas actualizaciones en Twitter en twitter.com/rachelappel.
Gracias a los siguientes expertos técnicos por su ayuda en la revisión de este artículo: Scott Klein y Miriam Wallace