mAPRS es mi proyecto personal de una aplicación para sistemas Android e iOS, diseñada para trabajar con APRS. No surgió porque faltaran en el mercado aplicaciones compatibles con APRS; ya existen varios programas de este tipo y muchos cumplen muy bien su función. El motivo era mucho más sencillo. Durante el uso diario de APRS me molestaba tener que cambiar constantemente los ajustes de forma manual, dependiendo de lo que estuviera haciendo en cada momento. Cuando conduzco, quiero aparecer de forma distinta que cuando me desplazo a pie. Cuando estoy en casa, debería enviarse otro conjunto de información. Cada vez tenía que acordarme de todo ello. Y fue entonces cuando surgió la pregunta: ¿por qué la aplicación no puede hacerlo por sí misma? Así comenzó a desarrollarse mAPRS.
¿De dónde surgió la idea de mAPRS?
Desde el principio, la premisa principal del proyecto fue muy concreta: la aplicación debía funcionar de forma autónoma en la mayor medida posible. No quería preguntarme antes de cada salida si había seleccionado el icono correcto. Tampoco quería cambiar manualmente de perfil después de aparcar el coche y comenzar a caminar. Ni quería acordarme de volver a cambiar los ajustes al regresar a casa. mAPRS debe reconocer la situación y reaccionar en consecuencia.
La aplicación determina si actualmente: conduzco, me desplazo a pie o estoy en casa. A partir de esta información, selecciona automáticamente los elementos adecuados que se transmiten a APRS, principalmente el icono, el comentario y el símbolo o signo correspondiente de la estación. De este modo, el usuario no tiene que cambiar manualmente la configuración cada vez. Esta automatización es precisamente el motivo principal por el que se creó mAPRS y, al mismo tiempo, la característica en torno a la cual desarrollo todo el proyecto.
Compatibilidad con APRS-IS
mAPRS se comunica con la red APRS-IS, es decir, con la parte basada en Internet de la infraestructura APRS. La aplicación prepara la información relacionada con la estación y la transmite a la red. De este modo, la posición y los demás datos también pueden visualizarse en otros servicios y aplicaciones que utilizan APRS-IS. Para mí, es muy importante mantener la compatibilidad con APRS. La automatización no debe crear una forma de funcionamiento propia y cerrada. Al contrario: mAPRS debe utilizar la infraestructura APRS existente, pero realizar por el usuario parte de las tareas que normalmente deben hacerse manualmente. Desde el punto de vista de la propia red, es una diferencia pequeña, pero desde el punto de vista de quien utiliza la aplicación a diario, es muy importante.
El track debe seguir siendo preciso
Uno de los elementos importantes de la aplicación es registrar y mostrar la ruta. Durante el desarrollo de mAPRS, quiero evitar que la optimización del funcionamiento de la aplicación se haga a costa de la calidad del track. Si me desplazo por una ruta, después quiero ver su recorrido real, no unos pocos puntos aleatorios unidos por líneas rectas. Por eso, los mecanismos responsables de enviar información a APRS y los relacionados con la creación del track no tienen que funcionar exactamente de la misma manera. La aplicación puede necesitar información detallada sobre el movimiento para funcionar correctamente y mostrar la ruta, aunque no sea necesario enviar inmediatamente toda esa información a APRS-IS.
El siguiente reto: el consumo de energía
Una aplicación que monitoriza la ubicación durante muchas horas puede convertirse fácilmente en uno de los mayores consumidores de energía del teléfono. Por eso, optimizar el consumo de batería es otra etapa importante del desarrollo de mAPRS. Sin embargo, no se trata de la solución más sencilla, consistente en comprobar la posición con menor frecuencia. Esto podría empeorar la calidad del track y la eficacia de la detección del modo de desplazamiento. El objetivo es encontrar una forma de utilizar los mecanismos de localización que permita a la aplicación recibir la información necesaria sin obligar al teléfono a realizar trabajo innecesario. Esto es especialmente importante durante un viaje largo o durante una actividad de todo el día al aire libre. mAPRS debería funcionar en segundo plano durante mucho tiempo, sin que sea necesario estar preguntándose continuamente cuánta batería queda en el teléfono.
Una aplicación desarrollada por etapas
mAPRS sigue en desarrollo. No obstante, procuro no introducir muchos cambios aleatorios al mismo tiempo. Cada versión nueva tiene un objetivo concreto: mejorar un elemento determinado, cambiar el comportamiento de la aplicación u optimizar un mecanismo existente. Después, la nueva versión pasa a la fase de pruebas. Este enfoque permite comprobar mucho más fácilmente si un cambio ha producido realmente el resultado esperado y si, al mismo tiempo, no ha afectado negativamente a algo que antes funcionaba correctamente. Esto es especialmente importante en una aplicación que trabaja con la ubicación en segundo plano. Algunos problemas no aparecen tras cinco minutos de uso. Solo se hacen visibles durante un viaje largo, una parada, un paseo o después de varias horas de funcionamiento. Por eso, las pruebas en condiciones reales son una parte muy importante de todo el proyecto.
No se trata de crear otra aplicación APRS
mAPRS no pretende competir en número de funciones con todos los programas existentes. Ese no era el objetivo del proyecto. Ante todo, quiero resolver un problema que yo mismo encontré al utilizar APRS. Si la aplicación puede detectar por sí sola que estoy conduciendo, ¿para qué tengo que cambiar manualmente el símbolo del coche? Si poco después empiezo a caminar, ¿por qué tengo que volver a entrar en los ajustes? Y si he regresado a casa, el teléfono también puede reconocerlo. Esta idea es precisamente la más importante para mí: APRS debe adaptarse a lo que hace el usuario, no el usuario a la aplicación.
Un proyecto con el que también aprendo mucho
mAPRS es a la vez un proyecto práctico y técnico. Para crearlo, tengo que combinar varias áreas completamente distintas: el funcionamiento del sistema, la localización, el trabajo de la aplicación en segundo plano, la comunicación de red, las particularidades de APRS, el análisis del movimiento y la optimización del consumo de energía. Además, hay que preparar nuevas versiones, realizar pruebas y completar todo el proceso de distribución de la aplicación. Cada etapa nueva revela problemas que a menudo no se ven al principio. Y eso es precisamente lo más interesante de este proyecto. mAPRS no nació como un producto terminado, planificado desde la primera hasta la última pantalla. Evoluciona junto con las pruebas y las ideas que surgen del uso real de la aplicación.
¿Qué será de mAPRS?
La idea fundamental no cambia: automatizar al máximo el trabajo con APRS, manteniendo el control sobre lo que hace la aplicación. Las siguientes etapas de desarrollo se centran principalmente en perfeccionar el reconocimiento de situaciones, el cambio correcto de perfiles, el funcionamiento de la localización, la forma de informar de la posición y la reducción del consumo de energía. También quiero que el usuario tenga información clara sobre lo que está haciendo la aplicación en cada momento y sobre los datos que transmite a APRS-IS. En cambio, no me interesa añadir funciones solo para que la lista sea más larga. Prefiero que unos pocos mecanismos importantes funcionen realmente bien.
mAPRS: menos cambios, más APRS
El proyecto comenzó con una molestia muy sencilla: cambiar constantemente y de forma manual los ajustes de APRS. De ahí surgió la idea de una aplicación que observa la situación y puede decidir por sí misma cómo debe mostrarse mi estación en cada momento. Conduzco. Camino. Estoy en casa. mAPRS debe reconocerlo y seleccionar adecuadamente el icono, el comentario y el símbolo APRS. Sin tener que acordarse de los interruptores. Sin entrar en los ajustes cada vez. Esa es precisamente la idea principal de mAPRS, y de ella surgió todo lo demás del proyecto.
La política de privacidad de la aplicación mAPRS se encuentra aquí.