A la hora de construir una aplicación móvil, es necesario definir como va a ser la arquitectura de la misma. Con esto nos referimos a que por lo general las aplicaciones móviles no son el núcleo de la aplicación en si mismo, si no una forma de entrada o consulta de datos. Por lo tanto, va a ser necesario definir como vamos a trabajar con estos módulos del sistema y como se van a integrar con nuestra sistema existente.
Una pregunta común al comenzar a trabajar con aplicaciones móviles es como debo estructurar mi base de conocimiento.
En la mayoría de los casos, vamos a partir de un sistema ya existente, en el cual teníamos resuelta la toma de datos por algún modulo del sistema, ya sea Win o Web, con cierta lógica asociada que quisiéramos reutilizar.
Existen distintas alternativas que podemos manejar:
En la mayoría de los casos no nos va a servir, pues, si nuestra base de conocimiento tiene un modulo de entrada de datos que podemos reutilizar, también tiene muchas cosas que no queremos tener en nuestro modelo móvil.
Por ejemplo, nuestro sistema de entrada de datos podría simplemente utilizar 3 tablas, mientras que la base de conocimiento tiene muchas más. No tiene sentido crear esta cantidad de tablas en el Pocket PC cuando solo usamos 3. Sin embargo parece muy util cuando se utiliza replicación de SQL Server como veremos más adelante.
Quizás esta sea la mejor opción, pues podemos quedarnos solo con aquello que necesitamos.
Consiste en crear una nueva base de conocimiento con aquellos objetos que vamos a utilizar en la aplicación móvil.
Tenemos dos alternativas, consolidar los objetos de la KB centralizada y recortarlos, o rehacer los objetos en nuestra nueva KB.
Con el fin de ilustrar la forma de plantear el entorno de desarrollo, veamos el siguiente ejemplo:
Se tiene una sistema dedicado a administrar servicios técnicos de PC's. El sistema consiste en manejar a partir de requerimientos de entrada, pedidos de services, asociarlos a un técnico, el cual va a realizar el service al cliente y al retornar registra el resultado del mismo.
Dicho sistema se tiene instalado en el local de donde parten los técnicos, y tradicionalmente se les presenta una planilla con los services que debe realizar en cada turno. El Técnico al retornar de su turno, debe ingresar los datos que rellenó en la planilla en el sistema.
Para manejar esta realidad se tiene un sistema con las siguientes transacciones:
Issue: Para manejo de los incidentes reportados por los clientes, y asignación del empleado que lo va a atender.
Employes: Manejo de empleados que hacen Service técnico
Customer: Datos de los clientes de la empresa
Assist: Transacción pararlela a la Issue donde el empelado registra los datos del incidente luego de atenderlo.
Con estas 4 transacciones podemos modelar de forma sencilla el manejo de incidentes, asignación de empleados y registro de clientes.
Ahora queremos darle a cada técnico un Pocket PC, de forma de cargar en el Pocket cada una de los incidentes que debe atender, así como los datos necesarios para que lo atienda.
Aquí nos surge una pregunta.realmente necesitamos toda la información que tiene el sistema central?
No nos sirve de nada tener todos los datos de todos los empleados, por ejemplo, ya que es algo que no voy a requerir.
Lo que vamos a hacer es consolidar las transacciones en una nueva KB y luego vamos a eliminar la transacción de empleados y recortar datos innecesarios de las restantes.
El resultado final es la siguiente estructura:
Issue: Se elimina referencia al empleado, así como la descripción de Cliente (por un tema de diseño de pantallas, como veremos mas adelante)
Customer: Solo nos quedamos con los datos de los clientes que nos interesan visto desde el punto de vista del técnico. No tiene sentido manejar la fecha de pago, o la dirección de cobro
Assist: Permanece incambiada.
Nótese entonces que hacemos dos recortes:
1 - Eliminamos transacciones que no nos interesan
2 - Eliminamos atributos dentro de transacciones que no nos interesan.
Esto se debe a que si bien los dispositivos móviles son computadoras, los recursos son limitados y debemos intentar recortar lo más posible la aplicación para tener solo aquellas cosas que necesitamos realmente.
Aún no definimos como vamos a comunicar el sistema centralizado con el sistema móvil. Tampoco como vamos a estructurar los form de la aplicación, eso lo veremos mas adelante.
A la hora de construir un sistema móvil se tiene que tener presente que en la mayoría de los casos este se debe integrar con un sistema central y que no nos va a interesar tener todo el sistema central en nuestro dispositivo.
Como alternativa podemos definir una nueva base de conocimiento importando solo aquello que necesitamos.