• 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

• 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)

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

if (Titanium.Network.networkType !== 

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

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();
}

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

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

// Global namespace
var myapp = {};

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

// 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);
}

// 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();

• 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ñ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

• Sustituimos el archivo de la base de datos remota
• Actualizamos el archivo de configuración con la fecha actual

• 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

• Apple iPhone 4S
• Samsung Galaxy SII con Android "Jelly Bean" 4.03

• 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

Introducción

En este artículo vamos a ver como administrar actualizaciones de paquetes en nuestro Ubuntu Server utilizando la herramienta aptitude. En un artículo anterior vimos como realizar actualizaciones en nuestro Ubuntu Server.

La herramienta aptitude no es más que una interfaz de APT o Advanced Packaging Tool (Herramienta de Empaquetado Avanzada) del sistema operativo Ubuntu. Es apropiada para tareas de administración de paquetes en servidores sin interfaz gráfica de usuario.

• Actualizaciones de seguridad. Paquetes que reciben actualizaciones de seguridad desde el repositorio security.ubuntu.com
• Paquetes actualizables. Paquetes que tienen una nueva versión disponible en los repositorios
• Nuevos Paquetes. Paquetes añadidos a Ubuntu desde la última vez que se borró la lista "Nuevos paquetes"
• Paquetes instalados. Listado de paquetes instalados en el servidor
• Paquetes no instalados. Listado de paquetes disponibles no instalados en el servidor
• Paquetes virtuales. Estos paquetes no existen, solo son nombres que otros paquetes suelen requerir o proporcionan alguna funcionalidad
• Tareas. Son grupos de paquetes que son instalados de forma conjunta para cumplir alguna funcionalidad, por ejemplo: dns-server, lamp-server o kubuntu-desktop

• Componentes de lógica de acceso a datos. Estos presentan una interfaz a la capa de negocio que abstrae de la forma en que se acceden a los datos almacenados, haciendo a la aplicación más fácil de configurar y mantener
• Componentes utilitarios y auxiliares. Consisten en librerías especializadas o APIs que permiten acceder, manipular o transformar los datos dentro de los componentes de de lógica de acceso a datos. Por lo general son suministrados por el fabricante del gestor de base de datos (Oracle, IBM, etc.)

• Cree un diseño general de su capa de acceso a datos

1. Identifique los requerimientos de las fuentes de datos (data sources)
2. Determine el enfoque de acceso a los datos
3. Elija como mapear estructuras de datos a los resultados de las fuentes de datos (data sources)
4. Determine como conectarse a las fuentes de datos
5. Elija la estrategia para tratar errores de conexión con las fuentes de datos

• Diseñe sus componentes de acceso a datos

1. Enumere las fuentes de datos a las que va a acceder
2. Decida el método de acceso para cada fuente de datos
3. Determine que componentes auxiliares o librerías son necesarios para facilitar el acceso el acceso a los datos así como las tareas de desarrollo y mantenimiento
4. Estudie si puede aplicar patrones de diseño en el acceso a los datos (Table Data Gateway, Query Object, Repository, etc.)

• Diseñe sus componentes auxiliares

1. Identifique que funcionalidades pueden moverse fuera de los componentes de acceso a datos y crear un componente auxiliar para su reutilización
2. Busque librerías de componentes auxiliares disponibles
3. Considere componentes auxiliares para solucionar problemas como conexiones, autenticación, monitorización o tratamiento de excepciones
4. Considere añadir logging a sus componentes auxiliares

• Seleccione la tecnología adecuada de acceso a datos. La tecnología de acceso a datos depende del tipo y volumen de los datos que necesitamos. Determinadas tecnologías son mejores en determinados escenarios. Por ejemplo, la recuperación de miles de registros por una única clave y si no hay necesidad de consultas complejas, podría llevarnos a utilizar un gestor de base de datos NOSQL en vez de un gestor SQL relacional clásico.
• Utilice la abstracción para implementar componentes de acceso a datos débilmente acoplados al sistema de gestión de base de datos. Esto nos permite no solo desarrollar cómodamente y mantener nuestra capa de acceso a datos, sino incluso migrar todos los datos de un gestor a otro con el mínimo o ningún impacto en nuestra aplicación Web
• Considere la mapear los datos obtenidos en objetos o estructuras de datos que son más simples de procesar en la capa de negocio
• Encapsule todas las funcionalidades de acceso a bases de datos dentro de la capa de acceso a datos. Esta capa tiene que ocultar a la capa de negocio todo lo relacionado con conexiones, mapeos y transformaciones básicas de datos, generar consultas, etc.
• Decida como manejar las conexiones. Como regla, la capa de acceso a datos tiene que manejar todas las conexiones a todas las fuentes de datos requeridas por la aplicación. Estudie como almacenar y proteger acorde a sus requerimientos de seguridad, la información que describe a estas conexiones.
• Determine como tratar las excepciones de datos. La capa de acceso a datos debe capturar todas las excepciones relacionadas con las fuentes de datos y las operaciones CRUD (Create, Read, Update & Delete – Crear, Leer, Actualizar y Borrar) relacionadas con la base de datos. Las excepciones producidas por los datos solo deben pasarse a la capa de negocio si afectan la funcionalidad o la respuesta de usuario de la aplicación
• Considere los riesgos de seguridad. La capa de acceso a datos debe de protegerse contra mecanismos de ataque que traten de borrar, corromper, alterar los datos o tomar control de la fuente de datos.
• Reducir el tráfico de datos siempre que sea posible.
• Considere el desempeño y la escalabilidad de la base de datos. Estudie los límites de acceso a datos de su aplicación. Realice pruebas de estrés y pruebas de carga que permitan encontrar esos límites acorde a las capacidades del entorno de Producción de su instalación. Recuerde que lo que en un entorno de test o de desarrollo es factible en términos de concurrencia, volumen de datos o respuesta de usuario no tiene nada que ver en un entorno de Internet con diferentes conexiones a diferentes velocidades, cientos o miles de usuario accediendo al mismo tiempo y miles de MB o GB transfiriéndose entre los servidores y los clientes en navegador que ejecutan nuestra aplicación

• Componentes de negocio. Encapsulan las reglas de negocio o la forma en que los datos adquiridos desde la capa de presentación deben ser manipulados o transformados acorde al problema que tenemos que resolver. Estos componentes pueden cambiar o evolucionar con los requerimientos de negocio.
• Entidades de negocio. Se utilizan para pasar o intercambiar datos entre componentes de negocio. Ejemplos típicos pueden ser las facturas, productos, contratos o clientes. Internamente están formados por estructuras de datos o clases de lenguajes orientados a objetos serializables.
• Flujo de trabajo. Muchos procesos de negocio son tratados como un conjunto de pasos dependientes unos de otros que deben ejecutarse coordinados y en un orden determinado. Un ejemplo clásico es la aprobación de un contrato que implica la aprobación de los términos y condiciones así como las firmas de los intervinientes. En muchas ocasiones estos flujos de trabajo son procesos de negocio de múltiples pasos que requieren intervención del usuario y por lo tanto pueden ser de larga duración.
• Fachada de aplicación. Una fachada de aplicación combina múltiples operaciones de negocio dentro de un único mensaje. Existen varias formas de enviar este mensaje desde una capa de presentación para que las operaciones de negocio puedan ser tratadas. Este es un componente opcional que proporciona otra facilidad de proceso a nuestra capa de negocio

• Crear un diseño general de la capa de negocio

1. Identificar los consumidores de la capa de negocio
2. Determinar como se va a exponer la capa de negocio
3. Determinar los requerimientos de seguridad de la capa de negocio
4. Determinar los requerimientos de validación de la capa de negocio
5. Determinar los requerimientos de caché de la capa de negocio
6. Determinar la estrategia de tratamiento de excepciones de la capa de negocio

• Diseñar los componentes de negocio

1. Identificar los componentes de negocio que la aplicación va a utilizar
2. Determinar las interacciones, acoplamiento y ubicación de los componentes de negocio
3. Seleccionar el soporte transaccional adecuado
4. Identificar como se van a tratar las reglas de negocio
5. Identificar los patrones que se ajusten a los requerimientos de negocio

• Diseñar las entidades de negocio

1. Identificar los formatos de datos comunes de las entidades de negocio
2. Seleccionar el formato de datos adecuado
3. Seleccionar el diseño correcto de la entidad de negocio
4. Seleccionar el tipo de serialización que vamos a necesitar

• Diseñar los componentes de flujos de trabajo

1. Identificar los escenarios de uso de flujos de trabajo
2. Determinar cuantas reglas van a ser tratadas
3. Determinar como van a ser tratadas las reglas
4. Seleccionar una solución de flujo de trabajo para nuestra aplicación
5. Crear componentes de negocio que soporten flujos de trabajo

• Decidir cuantas capas de negocio vamos a tener en nuestra aplicación Web. El uso de varias capas de negocio simplifica el mantenimiento de nuestra aplicación. Solo modificamos o evolucionamos la capa de negocio que sea necesario y no toda la capa de negocio lo cuál tendría un impacto mucho mayor
• Identificar las responsabilidades de nuestra capa de negocio.  Debemos crear una capa de negocio para procesar reglas de negocio complejas, transformaciones de datos y realizar validaciones.
• No mezclar diferentes tipos de componentes en la capa de negocio. Una de las misiones fundamentales de la capa de negocio es desacoplar la lógica de negocio de la capa de presentación y de la capa de acceso a datos
•  Reutilizar lógica de negocio común. Otra de las misiones fundamentales de la capa de negocio es la de crear en un espacio común, lógica de negocio que pueda ser reutilizable, simplificando el mantenimiento y reduciendo el tamaño de nuestra aplicación Web
• Identificar los consumidores de la capa de negocio. Esto nos va a ayudar a determinar como vamos a exponer nuestra capa de negocio (como otras capas de la aplicación van a interactuar con ella). Por ejemplo, si una aplicación externa va a interactuar con la capa de negocio, deberíamos exponerla como un servicio
• Reducir el tráfico (idas y vueltas) cuando accedemos a una capa de negocios remota. Esto de consigue con el uso de una interfaz basada en mensajes y con la implementación de una fachada de aplicación en nuestra capa de negocio. De esta forma con un solo mensaje podrían realizarse varias operaciones, en vez de realizar múltiples llamadas a diferentes métodos u operaciones de un servicio
• Evite al máximo el acoplamiento con la capa de presentación. Considere el uso interfaces basadas en mensajes, entre la capa de presentación y la de negocio. En la propia capa de negocio, utilice interfaces de objetos públicas, definiciones comunes de interfaces, clases abstractas o mensajes.

Introducción

• Componentes de presentación: Componentes de la interfaz que permiten a los usuarios interactuar con la aplicación Web. Renderizan (dibujan) y formatean la información que se quiere presentar así como capturan y validan las entradas de datos. Ejemplos clásicos son los botones, las etiquetas, los hipervínculos, los cuadros de texto, las tablas, etc. La mayoría de estos componentes vienen incluidos dentro del propio lenguaje HTML y otros se implementan en lenguajes de scripting para el navegador como Javascript.
• Componentes de proceso. Los componentes de proceso sincronizan y orquestan interacciones de usuario complejas. Estos componentes por lo general se implantan utilizando un Framework de JavaScript como Sencha o jQuery y pueden contener patrones de interacción embebidos (como el vista controlador) que simplifiquen el desarrollo y mantenimiento de interacciones complicadas por parte del usuario.

• Determinar como se van a presentar los datos. Seleccione el formato de su capa de presentación y decida como presentar los datos en su interfaz de usuario (en una columna, en dos columnas, con banners, con galerías de imágenes, etc.)
• Elija una estrategia de validación de datos. Apóyese en las facilidades que ofrecen tanto el HTML como JavaScript para proteger su aplicación Web de entradas de datos no deseadas
• Determine su estrategia de lógica de negocio. Teniendo claro que es lógica de negocio o proceso de datos y que es presentación de datos, podemos desacoplar (separar) las capas
• Establezca una estrategia de comunicación con otras capas. Si su aplicación tiene una arquitectura multicapas, elija como la capa de presentación se va a comunicar con la capa de negocios o con la capa de datos. Un patrón o modelo vista controlador puede simplificar este diseño.

• Utilice patrones relevantes en el diseño de la capa de presentación. Los patrones de diseño simplifican la implementación y mantenimiento de la capa de presentación y aportan la robustez de soluciones probadas y de éxito en la industria
• Diseñe siempre separando entre componentes de presentación y componentes de proceso. Cree componentes para renderizar y mostrar los datos y cree componentes para orquestar y sincronizar las interacciones complejas del usuario
• Considere las buenas prácticas en el diseño de interfaces de usuario (Human Interface guidelines). Aplique y ajuste estas prácticas generales a como se realizan en su organización e incluso en su propio país. No es lo mismo una página en chino mandarían que una página en alemán o en árabe. La información se lee de forma diferente, propia del lenguaje en que la estamos presentando. Un alemán leerá como todos los occidentales de izquierda a derecha, mientras que un árabe lo hará al revés. Considere los logotipos, eslóganes y colores corporativos propios de su organización, así como los colores adecuados para el texto y los controles en dependencia de la frecuencia de uso y destino de la aplicación Web a crear. No son los mismos colores ni imágenes los de una página Web para un casino o venta de juegos de PlayStation que los de Wikipedia, por ejemplo, donde quizás tenemos que pasar horas consultando información.
• Apóyese en encuestas, cuestionarios y entrevistas para conocer el tipo de presentación que el usuario de negocio demanda y ajuste el diseño lo más posible a sus requerimientos, necesidades y gustos