Aplicaciones Móviles Java (J2ME) - Una experiencia real

A continuación se relata la absoluta verdad sobre los desarrollos móviles en las condiciones latinoamericanas, más específicamente las Colombianas; aunque los estándares J2ME dicen una cosa, la realidad es muy distinta; la amplia variedad de dispositivos ocasionan que en muchos casos surjan contrariedades en el desarrollo. La experiencia que acá voy a relatar tuvo en mi concepto cada una de las eventualidades que podrían aparecer y retrasar un proyecto de desarrollo con componente móvil; sin embargo, cada uno de estas circunstancias fue superada con el tiempo, investigación y constancia para al final obtener un aplicativo estable en terreno y con todos los requerimientos del cliente.

El proyecto consistió en una aplicación móvil con componente geográfico, una serie de formularios, envío de datos en línea, almacenamiento de la información de una base de datos transaccional, GPS, entre otras.

La funcionalidad en términos generales consiste en asignar, mediante una aplicación web con componente geográfico (mapas digitales), trabajo a los operarios en terreno, para que ellos a su vez mediante el dispositivo móvil puedan visualizar (también mediante mapas) la ubicación de las direcciones de los predios que deben visitar, y establecer un orden de prioridad de ruta establecido fundamentalmente por la distancia entre el predio y el operario (vía GPS). El operario realiza la visita, digita la información en formularios y envía la información al servidor en tiempo real y pasa a realizar la siguiente visita. Adicionalmente al proceso principal, existen procesos secundarios que se realizan para auditar el trabajo de los operarios, como el envío de coordenadas GPS cada determinado tiempo, el almacenamiento de información dentro del dispositivo (si se accede a una zona donde el canal de transmisión tiene fallas), el ajuste de posición (latitud y longitud) de una visita en particular y todos los procesos generales de que dispone un visor de mapas digital como Google Maps.

El proyecto se dividió en dos fases, en la primera se evaluó la viabilidad de desarrollar un aplicativo para dispositivos móviles con capacidades geográficas y que lograra asemejar la mayoría de capacidades de un aplicativo desarrollado por una empresa privada (cuyo nombre no puedo exponer) y que ya era utilizado por un área de la empresa en particular. Con la gran diferencia de que la transmisión de información se efectuaría en línea y se lograran explotar las capacidades GPS del dispositivo (cuestiones que no eran aprovechadas por la otra aplicación).

La segunda fase consistía en, aprobada la primera, desarrollar todas las capacidades del aplicativo y adaptar dicho desarrollo a los nuevos equipos asignados, además de poner en productivo el desarrollo.

La primera fase fue aprobada en el tiempo establecido determinando así la viabilidad del aplicativo; para las demostraciones se utilizó un N85 8GB con soporte nativo java. En esta etapa se revisó el alcance de las capacidades del desarrollo, incluyendo gps, transmisión de datos en línea y un eventual trabajo desconectado. Con lo que se decidió desarrollar la segunda fase para la cual se tenían establecidos tres meses.

La segunda fase comenzó un mes después de lo establecido dado que era necesario coordinar las tareas a desarrollar y verificar el alcance obtenido del sistema. El desarrollo entonces siguió su curso y se decidió instalar el aplicativo en los dispositivos recientemente adquiridos, los cuales tienen capacidades de dispositivos de terreno: resistencia al agua, golpes, etc. Además de tener incluido el sistema operativo Windows Mobile. Lo cual lo hace apto para el trabajo con aplicativos de Microsoft y ESRI. Sus capacidades incluían también posicionamiento GPS con un margen de error bastante bajo.

La adaptación del aplicativo a estas características partiendo de la versión funcional del Nokia N95_8GB correspondió al primer contratiempo generado en el proyecto, dado que en primera instancia no incluía sistema operativo con soporte nativo de Java, por lo cual hubo una investigación requerida adicional, mediante la cual se probaron varias máquinas virtuales java entre las que se encuentran MySaifu (de origen Japones) Java Blend, Java ME SDK, e IBM J9, entre otras. Esta instalación y prueba de máquinas virtuales diferentes generó bastante retraso en el proyecto, y en algún momento se pensó en la posibilidad de desvirtuar la continuidad del prototipo, o la necesidad de utilizar otros dispositivos móviles con capacidades Java. De tal suerte que en la búsqueda de máquinas virtuales Java, se encontraba operatividad con el sistema solo en algunos de los módulos, es decir, algunas máquinas virtuales soportaban el almacenamiento de ficheros, pero no la interfaz gráfica con touch screen, otros, incluían soporte de la JSR 139 (GPS) pero no el almacenamiento de ficheros o funciones de transmisión de datos en línea. Finalmente en una página Rusa se encontró una máquina virtual con la mayoría de capacidades necesarias para que el aplicativo funcionara, exceptuando el soporte de la JSR 139 (GPS), dicha máquina virtual es una versión libre de la máquina virtual originaria de IBM.

Esta máquina virtual como se dijo anteriormente tenia soporte de ficheros, transmisión de datos en línea, interfaz gráfica con touchscreen, y en general todos los requerimientos necesarios para el funcionamiento del proyecto. Sin embargo su carencia del soporte de GPS era el factor que en este momento preocupaba la continuidad del proyecto. De tal forma ahora, meses después de la fecha de entrega establecida, la investigación se centró en lograr interactuar con el GPS del dispositivo sin el soporte nativo de la Máquina Virtual. De tal forma después de evaluar diferentes alternativas, se vio como opción el acceso a las funciones GPS a través de los puertos COM de los que dispone el dispositivo en cuestión. La investigación dio como resultado que la comunicación con dichos puertos se tenía que efectuar con un protocolo de comunicación particular, sin embargo las capacidades de la máquina virtual permitían acceder a puertos COM, lo cual dio como única alternativa probable la elaboración de un driver de conexión con el puerto COM del GPS mediante este protocolo, un trabajo arduo que evidentemente no se tenía contemplado en la ya desfasada planeación del proyecto. Paso siguiente, se desarrolló el driver de conexión con el GPS que actualmente está operativo en el sistema, en esta línea se presentaron algunos otros problemas más sencillos pero no menos importantes, como la desconexión por inactividad del GPS, el rango alto de error, la conversión de coordenadas de grados, minutos y segundos a coordenadas decimales, entre otros.

Después del trabajo de investigación y desarrollo, se logró integrar y ajustar el nuevo Driver de conexión GPS al resto de módulos del sistema, sin perder la funcionalidad del JSR 139 (para los dispositivos que si lo soportaran). En este momento ya el proyecto sufría un retraso de más de 6 meses, pero por el trabajo fuerte y los alcances obtenidos, se tenía fe en el producto final y se continuó con el proyecto.

En este punto la aplicación tenía acceso a ficheros, GPS, transmisión de datos en línea y contaba con acceso a la memoria interna del dispositivo, adicional a la funcionalidad de acceso a cartografía digital a través de servicios WMS (Web Map Services). Para este último punto, se contaba con una librería Free (gratuita) pero no Open Source, dicha librería se utilizó para las demostraciones de la fase I y que incluía características como el acceso a Google Maps, Yahoo Maps, puntos de interés, globos de información, etc. Ya en este punto se tenía certeza de la posibilidad de desarrollo de la mayoría de las funcionalidades requeridas en el proyecto. Se comenzó el desarrollo de los formularios propios requeridos por el proyecto, para el cual la empresa brindó un practicante programador como soporte al desarrollador principal para mitigar los retrasos del proyecto. De tal forma, se dictó según lo acordado contractualmente, una capacitación de 40 horas mediante la cual el practicante obtuvo el conocimiento suficiente para comenzar a generar los formularios requeridos. Tiempo después, al tener un avance sobre los formularios y al estar en un 80% el resto de funcionalidades: cartográficas, de GPS, de envío de datos en línea, de validación de información, era hora de evaluar el rumbo y el alcance obtenido hasta el momento en cuanto al proyecto. En dicha evaluación se encontraron algunos ajustes que en su momento parecían menores, se trataba del Zoom+ limitado en el mapa, en el cual no era posible definir claramente los predios a los que se debía llegar, o mover claramente puntos errados a su posición real. Otro requerimiento era el de enriquecer más la Interfaz de usuario haciéndola semejante a la de la Pocket, pues para este momento era una interfaz funcional pero bastante plana.

Estos dos puntos consistieron entonces en otro hito que se esperaba retrasara un poco más la culminación del proyecto, pero que no se veían como problemas graves. Sin embargo, los dos ajustes comprometieron seriamente (nuevamente!!!) la continuidad del proyecto. A continuación las causas de semejante problemática:

El primer problema, el zoom limitado, requería la modificación del código fuente de la librería utilizada pues internamente no plantea el acceso a más niveles de zoom y comprende únicamente del nivel 1 (más lejano) al 17 (máximo en google maps). Para la modificación de este código inicialmente se contactó a los desarrolladores de la librería quienes respondieron a la solicitud con algo como: en la siguiente versión dicha mejora será integrada en el proyecto, sin embargo, pasado algún tiempo no se generó dicha versión, y al momento de generarse una nueva, no incluía la modificación solicitada, efecto claro de no poder controlar los desarrollos de un tercero. Así que tocaba o pagar por la versión soportada de la librería Ya en este punto se hizo necesario decompilar el fuente de la librería, y realizar las modificaciones por nuestra cuenta y riesgo; se aprovecha para realizar algunas otras modificaciones, pero, sin embargo, la más importante, la mejora en los niveles de zoom no se consigue desarrollar, dado principalmente por defectos en la decompilación del fuente.

Aquí se hizo necesario, nuevamente elevar una alerta y generar una reunión con las personas responsables del proyecto puesto que el nivel de zoom no llenaba las expectativas del área. Dicha alerta trascendió al punto de vincular a otro desarrollador de aplicaciones J2ME de la compañía, quien hiciera las veces de interventor sobre el proyecto, y evaluara las condiciones y los contratiempos del desarrollo. Dicho interventor sugirió en última instancia, entregar el código en las condiciones a la fecha y cancelar la continuidad del proyecto. Sin embargo, dado el empeño y el sacrificio al que se había llegado hasta el momento, que el punto de injerencia a este momento era únicamente un nivel de zoom y que todo el resto de funcionalidades estaban listas, decidimos continuar.

Evaluamos entonces el cambio de librería cartográfica, aun cuando ello ocasionara la reconstrucción de cerca del 50% del código desarrollado; acá llegamos a la librería utilizada hoy día (mgmaps) de código abierto; se generaron pruebas de funcionalidades, iniciando por la principal en este momento: los niveles de zoom; después de algunas modificaciones logramos acceder a un nivel de zoom bastante aceptable donde el predio ocupa el 70% de la pantalla en el mayor nivel (aunque es libre el acceso a mayores niveles de zoom). Se comenzó a migrar el resto de funcionalidades cartográficas del aplicativo, lo cual, era bastante más duro que la primera librería, lo que retrasó aún más la culminación del proyecto.

Ya con este punto solucionado, era necesario tocar el segundo punto, el tema de la interfaz de usuario, dadas las limitaciones originales de JME (Java Micro Edition), se hizo necesario utilizar una librería por fuera del API estándar, que incluyera soporte de touchscreen, y soporte de colores, tamaños de letra, imágenes e íconos y validaciones, pero que permitiera el desarrollo cómodo de formularios. Allí se decide utilizar J2ME Polish; librería de código abierto con grandes capacidades visuales que solventa las necesidades del cliente. Era hora entonces de modificar el 50% restante del aplicativo, consistente en formularios e interacción con el usuario. Cuestión que requirió nuevamente tiempo de implementación.

Terminado este desarrollo, se procede a hacer pruebas en terreno, encontrando un nuevo y ya recurrente hito; la transmisión de datos, por la gran cantidad de información, no es estable, eventualmente se envían datos que no llegan a la base de datos o llegan corruptos. Es de aclarar que en este punto la transmisión se realizaba con una librería J2ME incluida en Netbeans, que convierte los datos en objetos, los serializa y los transmite por la red. Esta arquitectura es útil en condiciones donde la comunicación es muy buena, sin embargo, las condiciones de transmisión acá (para el proyecto) son limitadas y se encuentra que Movistar (que era el proveedor de internet para móviles) corta las tramas de datos demasiado largas. Así, se decide realizar el cambio de la arquitectura de transmisión de datos y desarrollar una librería propia congruente con las condiciones locales. Se procede a la investigación y se encuentra que en un país europeo las condiciones de comunicación son bastante similares a las nacionales y un aplicativo tiene el mismo problema, mediante el cual proporciona parte de una solución, digo parte porque el desarrollador argumenta que por cuestiones de propiedad intelectual de la compañía para la que trabaja no puede exponer claramente la solución que estableció al problema de comunicación. Sin embargo, estos tips, fueron la base de la arquitectura de comunicación actual del aplicativo. Donde esencialmente el contenido se lleva a un formato ligero y allí se comprime, se envía al servidor, se descomprime, se interpreta el contenido y se almacena en la base de datos. Esta nueva arquitectura de transmisión redujo el tiempo de transmisión y el ancho de banda utilizado a una razón de 80% menos. Y así se solucionó el problema.

Momento ya de entregar la aplicación faltaba un módulo necesario, el módulo de asignación de visitas, que no estaba incluido dentro de los productos a entregar por parte del contratista, pero que definitivamente era necesario para la operatividad del sistema. Después de unas charlas y teniendo en cuenta que el producto final se estaba entregando tiempo después de lo contemplado en el contrato, decidimos unilateralmente desarrollar una versión preliminar del aplicativo de asignación de visitas utilizando tecnologías de última generación, con cartografía interactiva y componentes JEE- AJAX. Se realiza el desarrollo y se entrega al cliente. Sin embargo la curva de aprendizaje por parte del personal ocasionaría que para las modificaciones requeridas se generen aún más retrasos en la puesta en marcha del proyecto, así se decide continuar con el módulo de asignación de visitas ya desarrollado en PHP por el cliente y ajustarlo a los requerimientos del área. Se inicia así una etapa de adaptación buscando satisfacer los requerimientos del área, etapa que dura alrededor de tres meses y en la cual se aprovecha para detectar problemas y realizar pequeños ajustes a la aplicación móvil. A tal punto que "Por FIN" al día de hoy se tiene la aplicación funcionando completamente en producción.

Lo más importante a resaltar acá es que con tanta adversidad encontrada durante el desarrollo siempre hay que ponerse la camiseta y atacar cualquier problema que surja sin importar que la solución requiera como en este caso el rediseño o la recodificación Completa del aplicativo. Y que más importante aún, con sacrificio y empeño se puede generar la base de lo que en el futuro puede ser una plataforma tecnológica reutilizable.