Mostrando entradas con la etiqueta mobile. Mostrar todas las entradas
Mostrando entradas con la etiqueta mobile. Mostrar todas las entradas

Actualizando una base de datos local desde un servidor remoto - Parte III (final)

En la parte final de este artículo, vamos a crear un mecanismo que permita descargar la base de datos alojada en el servidor remoto y alojarla en una ruta local en nuestro smartphone.

Para ello vamos a utilizar el Framework de desarrollo Titanium Mobile. La ventaja es que prácticamente el mismo código nos va a servir para desplegarlo en plataforma Apple o en plataforma Android con un mínimo o casi ningún cambio.

Estructura de la aplicación

La aplicación en Titanium Mobile está compuesta principalmente por dos archivos:
  • app.js que es la aplicación de pruebas del mecanismo de actualización
  • updatedb.js que es una biblioteca o librería que contiene el mecanismo de actualización
Para ambas se necesita declarar el espacio de nombres (namespace) común myapp:

myapp = {}

Otro aspecto importante es la naturaleza asincrónica de la actualización. La librería comienza la actualización que en dependencia de la conexión a Internet que tengamos, el tamaño de la base datos y la potencia de nuestro smartphone demorará segundos más o menos y nos notificará cuando este proceso termine.

La librería updatedb.js

La librería updatedb.js está compuesta por:
  • Una estructura de datos de configuración que especifica datos como la url del servidor Web donde se va a alojar la base de datos, el nombre de la base de datos, el nombre del archivo de configuración, etc.
  • Una función updatedb que permite la actualización de la base de datos local a partir de la base de datos remota y un conjunto de funciones auxiliares (helper functions)

Datos de configuración de la librería

Dato
Descripción
url
URL del servidor Web donde hemos alojado la base de datos
db
Nombre de la base de datos
cf
Nombre del archivo de configuración que contiene una fecha en formato YYYYMMDD (ejemplo 20130226)
timeout
Tiempo de respuesta para el servidor Web que hemos fijado en unos 10,000 milisegundos o 10 segundos por defecto
android
True indica que vamos a ejecutar la aplicación en un smartphone Android, False indica que vamos a ejecutarla en un smartphone de Apple
debug
En True indica si queremos visualizar mensajes que nos ayuden a la puesta a punto. Una vez lista para desplegar en Producción este campo debería ser False
debugcb
Debug Callback. Llama a esta función cuando se produce una situación de depuración
updatecb
Update Callback. Llama a esta función cuando termina la actualización de la base de datos
errorcb
Error Callback. Llama a esta función cuando se produce un error catastrófico durante la actualización
winx
Ventana principal de la aplicación
olddate
Fecha de la configuración local o última actualización que registramos
newdate
Fecha de la configuración remota

La función updatedb

Básicamente la función de actualización de la base de datos:

myapp.dbu.actind = 
Titanium.UI.createActivityIndicator({ height:25, width:25 });
    
// If the application is running in iOS
if (!myapp.dbu.android){
// Setting the activity indicator style
myapp.dbu.actind.style = 
    Titanium.UI.iPhone.ActivityIndicatorStyle.BIG;
// Adding the indicator to the main window
    myapp.dbu.winx.add(myapp.dbu.actind);
}


Crea un indicador de actividad para darle al usuario feedback de que está ocurriendo el proceso de actualización.

if (Titanium.Network.networkType !== 
    Titanium.Network.NETWORK_NONE){
// Get the remote config file with the date to update  
     myapp.dbu.getremoteconfig();
 }


Si hay conexión a Internet procesa el archivo de configuración remoto que está alojado en el servidor Web para verificar si hay alguna actualización.

var fcf = Ti.Filesystem.getFile(
    Ti.Filesystem.applicationDataDirectory,myapp.dbu.cf);

// if there is not a configuration file 
// in the application directory     

if (!fcf.exists()){
   // It's the first time we need to update 
   // the database and no network connection 
   var alertDialog = Titanium.UI.createAlertDialog({
       title: 'WARNING!',
       message: 'You need an internet connection'+ 
                'to update your application data!',
       buttonNames: ['OK']
       });
   // Show alert dialog
      alertDialog.show();
  // Close application because 
  // there is not information or data to process
      myapp.dbu.winx.close();
}

Si no hay conexión a Internet busca si hay un archivo de configuración local en nuestro smartphone. Si no existe, es la primera vez que se realiza la actualización por lo que terminamos con un mensaje de error ya que no es posible actualizar nuestra aplicación.

if (myapp.dbu.updatecb != null) {
     myapp.dbu.updatecb();
 }


Si a pesar de que no hay conexión, ya teníamos una actualización previa, llama a la función updatecb() para que la aplicación acceda a la base de datos.

Creando la aplicación demo

Creamos una aplicación en Titanium Mobile y añadimos la librería updatedb.js a la carpeta Android en Recursos. A continuación, borramos el contenido de app.js y añadimos lo siguiente:

// Background color
Titanium.UI.setBackgroundColor('#000');

// Global namespace
var myapp = {};

// Application main windows
var win1 = Titanium.UI.createWindow({
    title:'DemoDB',
    backgroundColor:'#fff',
    exitOnClose: true
});


Lo primero establece el color de fondo de la ventana de aplicación a negro. Luego declaramos el espacio de nombres global y creamos una ventana a la que pondremos el título ‘DemoDB’ con color de fondo blanco y que cuando se cierre termine la ejecución de la aplicación.

Luego escribimos la función que va acceder a nuestros datos una vez que termine la actualización:

// Function to list database content
var showdatabase = function()
{  
   // Open database 
   var db = Ti.Database.open('bestres.sqlite3');
   // Execute a query to get a recordset
   var restaurants = 
   db.execute('select name,area,style from restaurants');
   var s = "";
   // while there are records in the recordset 
   while (restaurants.isValidRow()){
     // Get the fields content     
     s += "NAME= "   + restaurants.fieldByName("name") + 
     ",AREA= "  + restaurants.fieldByName("area") +
     ",STYLE= " + restaurants.fieldByName("style") +  ";";
     // Navigate to the next record     
     restaurants.next();
   }
   // Close the recordset
   restaurants.close();
   // Show the records content 
   alert("DATABASE CONTENT => " + s);
}


La función abre la base de datos local sqlite3 local llamada besares.sqlite3 y ejecuta una consulta que devuelve el nombre, area y estilo de los restaurantes almacenados. Luego realiza un bucle mientras se reciban filas de datos y compone una cadena de caracteres con la información, cierra la conexión y muestra la cadena de caracteres formada en una ventana de alerta (popup window).

En este momento podríamos utilizar el resultado de la consulta para rellenar una lista o un grid de nuestra aplicación con los datos actualizados.

Por último añadimos el siguiente código:

// Including library 
Ti.include('updatedb.js');

// Configuring database access
myapp.dbu.url      = 'http://ayalawilson.com/apps/demodb/';
myapp.dbu.db       = 'bestres.sqlite3';
myapp.dbu.cf       = 'bestrescf';
myapp.dbu.debug    = true;
myapp.dbu.updatecb = showdatabase;
myapp.dbu.winx     = win1;

// Updating database
myapp.dbu.updatedb();

// On resume event show database
Ti.App.addEventListener('resume', function() {
      showdatabase();
});

// Open the application main window
win1.open();


Incluimos la librería updatedb.js y configuramos:
  • La url de la carpeta en el servidor Web donde se encuentra la base de datos
  • El nombre de la base de datos
  • El nombre del archivo de configuración que contiene la fecha de actualización
  • Ponemos a debug en true para ver mensajes de depuración
  • Indicamos que el updatecb (Update Callback) será la función showdatabase() que hemos creado previamente
  • Indicamos que la ventana de la aplicación será win1
A continuación llamamos a la función que actualiza la base de datos e indicamos un par de cosas más:
  • Añadimos al evento ‘resume’ (cuando pase de estar minimizada a tener el foco de ejecución) ejecute la función showdatabase() para mostrarnos los datos
  • Abrimos la ventana principal de la aplicación para comenzar su ejecución

Como actualizar la base de datos remota en el servidor
  • Sustituimos el archivo de la base de datos remota
  • Actualizamos el archivo de configuración con la fecha actual
Como se realiza la actualización local

Los terminales móviles cuando arranca la aplicación van al servidor Web e inspeccionan la fecha del archivo de configuración remoto. Si la fecha remota es mayor que la fecha de configuración local de la última actualización, se actualiza la base de datos local (borra la base de datos local y descarga la base de datos remota) en todos los terminales.


Si no hay conexión a Internet en el momento que arranca la aplicación pueden ocurrir dos cosas:
  • Que exista la base de datos local (descargada en otro momento). En ese caso, la aplicación utiliza los datos locales ya descargados
  • Que no exista la base de datos local (la aplicación nunca se ha iniciado). En esta caso nos presenta un mensaje de error y termina
Terminales probados
  • Apple iPhone 4S
  • Samsung Galaxy SII con Android "Jelly Bean" 4.03
Recomendaciones finales

Este escenario de descarga de la base de datos local desde un servidor remoto funciona muy bien para:
  • Aplicaciones que necesitan operar con bases de datos en modo desconectado (offline), lo que permite que un usuario puede consultar la información deseada viajando por el metro o en el campo o en la carretera o en zonas de difícil o ninguna cobertura
  • Bases de datos relativamente de pequeño tamaño para no consumir mucho ancho de banda con las descargas
  • Bases de datos de solo lectura donde los usuarios solo consumen información, pero no aportan nada (ni comentarios, ni ratings, etc.)
  • Actualizaciones poco frecuentes (los mejores restaurantes de una ciudad no cambian todas las semanas)
  • La base de datos, al ser el núcleo de la información y no estar embebida en una carpeta de recursos de nuestra aplicación, permite que esta pueda actualizarse si tener que actualizar la aplicación completa

El código del proyecto

El proyecto está alojado en Google Code en http://code.google.com/p/local-database-updates-from-remote-http-server/. Sois totalmente libres de modificarlo y adaptarlo a vuestro gusto y necesidades.



Introducción al framework Appcelerator Titanium

Introducción

Appcelerator Titanium es una plataforma para desarrollo de aplicaciones de escritorio y móviles (teléfonos inteligentes y tablets) basada en tecnologías Web.

La idea fue lanzada por Appcelerator Inc. en el año 2008 y el número de desarrolladores que la utilizan supera hoy los 390,000 con más de 50,000 aplicaciones creadas. 

La clave de la popularidad de esta plataforma reside en que el framework Titanium utiliza tecnologías utilizadas en el desarrollo Web, como el lenguaje JavaScript, para producir aplicaciones nativas que puedan ejecutarse sobre los sistemas operativos Apple iOS y Google Android.

Esto hace que muchos desarrolladores con perfil o formación en el mundo Web, encuentren muy fácil la utilización de esta plataforma para producir aplicaciones con un mínimo de conocimientos sobre el framework.

Otra gran ventaja para los desarrolladores es la portabilidad y el mantenimiento de las aplicaciones creadas. Una aplicación escrita en Titanium Mobile para iOS es casi un 70-80 % la misma escrita para Android. Solo son necesarias unas pocas llamadas API propias de la plataforma donde se va a ejecutar la aplicación para completarla.

Esto permite crear una especie de base común y añadir unas pocas funciones y variables adicionales específicas de la plataforma, simplificando notablemente el mantenimiento y evolución de las aplicaciones.

Otra característica importante es que el lenguaje JavaScript en el que escribimos nuestra aplicación, a diferencia de otros frameworks como jQuery o Sencha, no es interpretado por el navegador de Internet del dispositivo móvil.

Desde este punto de vista Titanium Studio se comporta como una especie de generador de programas. El código producido a partir del lenguaje JavaScript es traducido al lenguaje nativo de la plataforma donde se ejecutará la aplicación (Objective-C para Apple iOS o Java para Google Android) para luego ser compilado a código nativo.

Esto permite crear aplicaciones más pequeñas, rápidas y eficientes que aquellas que se ejecutan interpretadas bajo un framework de JavaScript convencional.

Características principales














  • Soporta el desarrollo de aplicaciones móviles multiplataforma
  • Con una sola base de código, pueden producir aplicaciones móviles Web, Android y iOS
  • Se desarrolla utilizando un lenguaje basado en JavaScript en un entorno de desarrollo integrado basado en Eclipse (Aptana Studio)
  • Aumenta en más de un 70 % la productividad al escribir aplicaciones
  • Permite utilizar la experiencia de los desarrolladores en tecnologías y estándares Web
  • Extensibilidad ilimitada del propio framework Titanium añadiendo nuevos módulos
  • Permite crear experiencias de usuario atractivas utilizando servicios en la nube tales como las notificaciones PUSH y los check-ins
  • Está muy bien documentado
  • Tiene una gran comunidad de desarrolladores que intercambian ideas, consejos y ejemplos
Entorno de desarrollo




El entorno de desarrollo basado en Aptana Studio (compañía adquirida por Appcelerator en 2011) es muy intuitivo y fácil de utilizar. 

La versión actual es la 2.1 y tanto el entorno de desarrollo como el framework se actualizan periódicamente vía Web.

Para poder instalar el Titanium Studio tenemos que tener unos 2 GB de memoria RAM libres y el Oracle JDK instalado. Para Windows se necesita la versión de 32 bits de JDK, no importa si el Windows de es 32 ó 64 bits.

Los binarios para su instalación están disponibles en Mac OSX, Windows y Linux de 32 ó 64 bits.

A pesar de que podemos instalar Titanium Studio en estos tres sistemas operativos tenemos las siguientes limitaciones:
  • Para Windows y Linux solo podemos desarrollar aplicaciones para Google Android. Esto se debe a que el entorno y las herramientas de desarrollo para Apple iOS solo pueden instalarse en Mac OSX
  • Para Mac OSX podemos desarrollar aplicaciones para Android y iOS debido  a que es posible instalar tanto las herramientas de desarrollo de Apple (XCode) como las de Android (Android SDK)
Así que para desarrollar verdaderamente nuestras aplicaciones multiplataforma necesitaremos un Mac. 

Literatura















A pesar de la corta edad de esta plataforma, ya se han escrito y publicado varios libros, como:
Nuevos acuerdos

Recientemente el fabricante de smartphones canadiense Research in Motion, ha logrado un acuerdo con Appcelerator Inc. para incluir su nueva plataforma Blackberry 10 en Titanium Studio.

Esto amplía de manera oficial a una nueva plataforma, la capacidad de portar o crear aplicaciones ofrecida por Titanium Mobile.

















Actualizando una base de datos local desde un servidor remoto - Parte III

La base de datos local







Nuestra base de datos local la vamos a crear en SQLite3. Este es un pequeño gestor de base de datos relacional desarrollado por Richard Hipp en el año 2000. Es una base de datos de dominio público, bastante potente para su pequeño tamaño, que implementa casi todo el estándar ANSI SQL-92 incluyendo transacciones atómicas, consistencia en la base de datos, aislamiento y durabilidad, triggers y casi todas las consultas del lenguaje SQL.

Dado su eficiencia, pequeño tamaño, bajo consumo de memoria y a la posibilidad de incorporar el motor relacional a nuestras aplicaciones en forma embebida (añadiendo una librería más), SQLite3 ha sido seleccionada por grandes fabricantes de dispositivos móviles o smartphones como la base de datos relacional oficial para desarrollar aplicaciones. Estamos hablando de Apple, Google y Research in Motion (Blackberry).

Como nuestro ejemplo es muy simple, solo vamos a crear una tabla con tres campos de tipo texto: Name (nombre del restaurante), Area (zona de Madrid donde se ubica el restaurante) y Style (estilo de la cocina del restaurante).

Creación de la base de datos

Lo primero es tener un cliente de base de datos SQLite. Como yo trabajo casi todo en Ubuntu Linux, tengo instalado SQLiteMan (SQLite Manager). Es un programa muy intuitivo y fácil de utilizar que está en los repositorios oficiales de Ubuntu, por lo que podemos instalarlo muy fácilmente desde un terminal:

sudo apt-get install sqliteman

Si estás utilizando otro sistema operativo, hay versiones de este programa para Windows y Mac OSX desde su propia página de descarga.

El proceso de creación de la tabla es muy simple:















Creamos una nueva base de datos que yo he llamado bestres.sqlite3 y en ella la tabla restaurants con los campos name, area y style.

Insertando los datos de los restaurantes

Como solo vamos a rellenar 10 registros, yo voy ejecutando consultas INSERT que van metiendo los datos de los restaurantes que obtuve de la página Web que publicó el ranking.


















Para ahorrar un poco vuestro trabajo he exportado la base de datos creada a un script SQL con la opción "Dump Database":


















El script bestres.sql resultante es el siguiente:


PRAGMA foreign_keys=OFF;
BEGIN TRANSACTION;
CREATE TABLE "restaurants" (
    "name" TEXT NOT NULL,
    "area" TEXT NOT NULL,
    "style" TEXT NOT NULL
);
INSERT INTO "restaurants" VALUES('Bar Tomate','Chamberi','Italian with International Vibe');
INSERT INTO "restaurants" VALUES('Casa Alboroque','Madrid Centre','Modern Spanish');
INSERT INTO "restaurants" VALUES('Diverxo','Tetuan','Spanish-Mexican Fusion');
INSERT INTO "restaurants" VALUES('El Paraguas','Madrid  Centre','Traditional Spanish');
INSERT INTO "restaurants" VALUES('Sudestada','Chamberi','Asian');
INSERT INTO "restaurants" VALUES('Taberna Laredo','El Retiro','Tapas');
INSERT INTO "restaurants" VALUES('Tsunami','Chamberi','Best sushi');
INSERT INTO "restaurants" VALUES('La Gabinoteca','Chamberi','Avante-garde gastrobar');
INSERT INTO "restaurants" VALUES('Sergi Arola Gastro','Chamberi','Modern Spanish');
INSERT INTO "restaurants" VALUES('Cilantro','Chamberi','Tapas');
COMMIT;


O si queréis, podéis descargar directamente la base de datos y el script de mi servidor Web desde esta ruta.

Desplegando la base de datos

Una vez creada y actualizada la base de datos, tenemos que desplegarla en un servidor Web. Obviamente tenemos que tener un hosting donde poder desplegarla. Usaremos el protocolo FTP para subir la base de datos a nuestro hosting y para subir también nuestro archivo de configuración.

Yo utilizo como cliente de FTP al maravilloso FileZilla que también está en los repositorios de Ubuntu:


sudo apt-get install filezilla

Al igual que SQLiteMan, es posible tener FileZilla para Windows o Mac OSX desde su página oficial de descargas.


En el sitio Web en cuestión, creamos en el directorio raíz la carpeta apps que es donde vamos a desplegar recursos remotos de nuestras aplicaciones y dentro la carpeta demodb que es el nombre de nuestra aplicación de pruebas.

En la ruta /public_html/apps/demodb subimos por FTP nuestra base de datos y el archivo de configuración.

Este archivo de configuración, es un archivo texto de nombre demodbcf que contiene la fecha del día en que hemos subido la base de datos en el formato yyyymmdd. Por ejemplo, yo desplegué la base de datos ayer, así que el archivo de configuración contiene el texto "20121205".

Este archivo de configuración contendrá siempre la fecha de actualización de nuestra base de datos SQLite.








Actualizando una base de datos local desde un servidor remoto - Parte II

Escenario completo



Vamos a analizar el escenario de esta aplicación:

  • El desarrollador, empresa o responsable del ranking de restaurantes crea la base de datos 
  • La base de datos es desplegada en un servidor Web desde donde va a ser descargada
  • Los usuarios descargan la base de datos en sus terminales para poder consumir la información
Teniendo claro como vamos a desplegar y desde donde vamos a descargar nuestra base de datos local, nos queda crear un mecanismo de actualización que permita actualizar la base de datos local sobre escribiéndola con una copia remota que el desarrollador ha actualizado o copiado en el servidor Web.

Mecanismo de actualización

El mecanismo de actualización está basado en un archivo de configuración que contiene la fecha de la última vez que se desplegó la base de datos en el servidor. Este archivo es desplegado en el servidor remoto y también es copiado en una carpeta local de datos de nuestra aplicación.



Cuando se ejecuta la aplicación en el terminal, un evento lanza la actualización de la base de datos. Esta actualización consiste en comparar la fecha del archivo de configuración remoto con la del archivo de configuración local. Si la fecha local es menor que la fecha remota, es porque la base de datos remota es una nueva versión.

En este caso, se descarga la base de datos remota y se actualiza el archivo de configuración local con la fecha remota una vez concluida la descarga.

Si el archivo de configuración no existe, es porque la aplicación nunca ha descargado la base de datos. En este caso se procede directamente a la descarga de la base de datos remota y del archivo de configuración.

De esta manera es posible actualizar periódicamente nuestra base de datos local a partir de la base de datos desplegada en un servidor Web remoto.

¿Por qué tiene que ser un servidor Web donde alojemos la base de datos?

La respuesta es muy simple: la mayoría de los frameworks de desarrollo de aplicaciones móviles soportan llamadas HTTP o la creación de clientes HTTP. La base de datos para una llamada HTTP tiene el mismo tratamiento que si descargáramos cualquier otro recurso de nuestra aplicación como un vídeo, una imagen, etc.

El servidor Web es un programa que se ejecuta de manera continua en un ordenador conectado a Internet, manteniéndose a la espera de peticiones de ejecución realizadas por los usuarios. Con comandos GET es posible descargar desde el servidor el archivo de configuración y la base de datos.

El servidor Web se encarga de responder a las peticiones GET de manera adecuada, entregando la información que solicitamos y de manera automática y desatendida, por lo que podemos hacer la actualización de la base de datos en cualquier momento.

Actualizando una base de datos local desde un servidor remoto - Parte I

















Introducción 

En este artículo vamos a ver como actualizar una base de datos local descargándola de un servidor Web remoto.

Lo primera pregunta es ¿donde utilizar este enfoque? 

En ocasiones tenemos una aplicación mobile que utiliza una base de datos en modo de solo lectura. Es decir, los usuarios no actualizan la información contenida en la base de datos, solo la consumen.

Esta base de datos a lo largo de la vida de la aplicación, tiene una información que se actualiza con el tiempo.

Pongamos el ejemplo de una lista de los 10 mejores restaurantes de la ciudad de Madrid. Esta perfectamente claro que aunque alguien haga el ranking de los mejores restaurantes , el llevar esta información a una aplicación de móvil cumple con las siguientes características:

  • El usuario no decide cuál es el mejor restaurante, quien elabora el ranking asume esa responsabilidad
  • El listado de los mejores restaurantes solo se puede consultar, no se puede modificar ni borrar
  • El ranking de los mejores restaurantes se elabora siguiendo una serie de posibles criterios que transcurren en el tiempo (calidad de la comida, decoración, ambiente, calidad del servicio, etc.) Esto quiere decir que no es probable que esta lista cambie ni diaria ni semanalmente. Como mínimo para que sea seria deberíamos elaborarla o actualizarla todos los meses
  • La base de datos que contenga la lista de restaurantes, será actualizada todos los meses en todos los terminales móviles que ejecuten nuestra aplicación
El uso de una base de datos local actualizada de manera remota tiene una serie de importantes ventajas prácticas:

  • La información puede ser consultada de manera offline. Cuando no estamos conectados, los usuarios pueden ver en zonas sin cobertura (haciendo un picnic en el campo o en una estación de metro) a que restaurante van a cenar hoy por la noche.
  • Disminuye el tráfico de red. Solo descargamos la información una vez al mes o cuando haga falta actualizarla. Si lo hacemos mensual, el ancho de banda contratado solo se afecta una vez. Por ejemplo si tenemos una base de datos de 100 MB y un contrato de 1 GB (1024 MB) de transferencia mensual, esta aplicación consumiría esta cantidad una vez al mes dejando unos 924 MB para el resto de las aplicaciones.
  • Velocidad en las consultas. Las consultas a la información guardada son muy rápidas porque solo dependen de la potencia del terminal donde se está ejecutando nuestra aplicación. Muchos smartphones de última generación incluyen procesadores de 2 ó 4 núcleos y más de 512 MB de memoria operativa, más que suficientes para una aplicación de base de datos.
 Entre las desventajas de este enfoque están:
  •  La información no tiene una actualización inmediata. Si un restaurante cierra hoy o cambia de nombre o de dueño, los cambios no se reflejan hasta la próxima actualización de la base de datos
  • Pérdida de rendimiento.Si el volumen de información es muy grande, el rendimiento de la base de datos local puede malo al intentar recuperar datos entre miles o millones de registros
  • Descargas muy grandes que consumen mucho ancho de banda.La descarga de bases de datos locales muy grandes puede obligarnos a solo descargarlas conectados a una red Wi-Fi (muchas aplicaciones y juegos ya nos obligan a ello por el tamaño de los datos que se descargan en local)
En este artículo, y perdonando los rankings oficiales o de preferencia de muchos usuarios, utilicé una lista de los mejores restaurantes de Madrid tomada de la página http://worldtop7.com/best-restaurants/Madrid/Spain/Europe a día de hoy.

Lo importante es disponer de una información que no varíe mucho, que pueda actualizarse mensualmente y desplegarse en una base de datos dentro de una aplicación mobile.

Bases de datos en dispositivos móviles – Estrategias de implementación


Base de datos local con datos estáticos

Base de datos de solo lectura en la carpeta de recursos

Base de datos de solo lectura descargada a la carpeta de datos de aplicación desde un servidor remoto en Internet


Características

  • La información no es modificada por los usuarios
  • La información se puede actualizar con cambios de versiones de la aplicación si va en la carpeta de recursos
  • La información se puede actualizar con cambios de versiones de la base de datos descargada desde un servidor remoto por Internet
  • Los mismos datos son enviados a todos los usuarios
  • Puede operar en modo desconectado
  • El volumen de datos va incluido en el propio tamaño de la aplicación lo que influye en su descarga y en el espacio que ocupa en el terminal móvil si la base de datos va en la carpeta de recursos
  • El volumen de datos no influye en la descarga de la aplicación, pero si en el tamaño que ocupa en el terminal móvil si los datos son descargados desde Internet
  • La descarga de datos desde Internet obliga a una política de actualización y versionado de la base de datos

Ejemplos

  • Datos de un juego (jugadores, circuitos de carrera, laberintos y otra información propia del juego que complemente su iconografía)
  • Datos de una aplicación de procesamiento de imágenes (marcos, efectos, escenas, etc.)
 Base de datos local con datos dinámicos


Base de datos creada por la aplicación

Base de datos copiada desde la carpeta de recursos.

Características
  • La información es modificada por los usuarios
  • La base de datos está vacía o contiene algunos datos como ejemplo
  • La información se actualiza a voluntad del propio usuario
  • La base de datos no puede residir en la carpeta de recursos de la aplicación, ya que es una zona de solo lectura. 
  • La base de datos se puede crear mediante la ejecución de sentencias que definan su esquema
  • La base de datos vacía se puede copiar desde la carpeta de recursos a la carpeta de datos
  • Los datos no se comparten
  • Puede operar en modo desconectado
  • Una opción de la aplicación puede vaciar la base de datos eliminando todos los datos introducidos
  • Inicialmente el volumen de datos no importa porque la base de datos viene vacía
  • Con el tiempo el volumen de datos crece según el usuario utilice la aplicación
  • Los cambios de versión de la aplicación no deberían afectar a los datos disponibles
Ejemplos
  • Un organizador personal
  • Una lista de compras
  • Una lista de tareas
  • Una galería de música o fotos
Base de datos remota con datos estáticos


Características

  • La información no es modificada por los usuarios
  • La información se actualiza siempre en el servidor remoto por los autores de la aplicación
  • No se descarga ninguna información en local por lo que la aplicación es relativamente pequeña
  • Tiene que operar de manera conectada
  • Los mismos datos son enviados a todos los usuarios
 
Ejemplos

  • Consulta de hoteles
  • Consulta de viajes
  • Consulta de vuelos
  • Búsqueda de sitios cercanos por geo-posicionamiento
Base de datos remota con datos dinámicos


Características

  • La información es constantemente modificada por los usuarios
  • La información se actualiza siempre en el servidor remoto
  • No se descarga ninguna información en local por lo que la aplicación es relativamente pequeña
  • Tiene que operar de manera conectada
  • Los mismos datos son compartidos por muchos usuarios
 
Ejemplos

  • Redes sociales de todo tipo (Facebook, Twitter, LinkedIn, etc.)
  • Opiniones sobre sitios
  • Juegos multi-jugador en la red


Base de datos en dispositivos móviles – ¿Remota o Local?


Los criterios para elegir el tipo de base de datos a utilizar básicamente son:

  • Datos dinámicos o estáticos (actualizables por el usuario o no)
  • Volumen de datos (poco volumen de datos vs. grandes volúmenes)
  • Información compartida (información privada de un usuario vs. compartida entre múltiples usuarios)
  • Operación desconectada de la red o el servidor de donde originalmente provienen los datos (consulta de la información en modo conectado u online vs. consulta de la información en modo desconectada u  offline)


Característica
Base de Datos Local
Base de Datos Remota
Datos dinámicos
SI
SI
Datos estáticos
SI
SI
Poco volumen de datos
SI
NO
Gran volumen de datos
NO
SI
Información compartida
NO
SI
Información no compartida
SI
NO
Operación desconectada (offline)
SI
NO
Operación conectada (online)
NO
SI

De la tabla anterior, podemos interpretar que:

  • Con datos dinámicos podemos tener bases de datos locales o remotas. El criterio es si los datos son compartidos con otros usuarios, en cuyo caso usaríamos una base de datos remota o si son privados de un único usuario con lo que sería más adecuada una base de datos local.
  • Con datos estáticos podemos tener bases de datos locales si son de muy poco volumen. Si son grandes cantidades de datos deberían residir en una base de datos remota.
  • Con un gran volumen de datos la opción siempre será una base de datos remota.
  • Con poco volumen de datos, sobre todo si no es necesario compartirlos la elección será la base de datos local
  • La información compartida será siempre en una base de datos remota a donde se conectarán múltiples usuarios
  • La información no compartida podría estar en local
  • Si es necesario operar de manera desconectada u offline, una base de datos local es una buena opción que puede brindar información en el metro, en el campo, fuera de cobertura de antenas, etc.
  • Si es necesario operar de manera conectada, una base de datos remota siempre podrá consultarse, asumiendo el usuario que cuando no hay conexión, tampoco trabaja la aplicación.

De manera general podemos extraer como conclusiones generales que:

  • Con datos dinámicos o estáticos, de poco volumen, no compartidos y con posibilidad de operar sin conexión del dispositivo a ninguna red, la elección es una base de datos local
  • Con datos dinámicos o estáticos,  de gran volumen de información, compartidos y que siempre puedan ser consultados de manera conectada, la elección es una base de datos remota

Por último, queremos destacar que no todo es blanco o negro:
  • Las bases de datos locales pueden residir en un servidor remoto y descargarse en local en el terminal. 
  • Una aplicación puede tener una base de datos local, sin embargo realizar consultas a bases de datos remotas. 
  • Algunas aplicaciones pueden almacenar datos en una base de datos local de manera desconectada y luego transferirlos a una base de datos remota en el momento en que tengan conexión.


Ejemplos de aplicaciones

Base de datos
Datos
Ejemplos
Local
  • Información introducida por el usuario. 
  • Poco volumen.
  •  No compartidos.

  • Una lista de compras
  • Una lista de tareas
  • Una galería de fotos
  • Una galería de notas de voz
  • Una galería de música


  • Información que se presenta al usuario proporcionada por la aplicación
  • Poco volumen
  • Compartida entre todos los usuarios de la aplicación

  • Una lista de bares de una ciudad
  • Una lista de colegios de una ciudad

Remota
  • Los usuarios alimentan la información de la aplicación
  • Gran volumen de datos
  • Compartida entre todos los usuarios de la aplicación

  • Redes sociales (se comparten mensajes, fotos, localizaciones, etc.)

  • Información que se presenta al usuario proporcionada por la aplicación
  • Gran volumen de datos
  • Compartida entre todos los usuarios de la aplicación

  • Información de vuelos, hoteles o alquiler de coches de un país o región del mundo








Entradas antiguas Inicio