Una App refurbished
Constantentemente las aplicaciones requieren de modificaciones para poder seguir operativas o satisfacer nuevas funcionalidades necesarias. En otros casos el código de los programas puede necesitar cambiarse para obtener una app funcionando. Acá mi experiencia atacando los dos frentes.
El comienzo
Hacía poco más de un año que había empezado a trabajar con tecnologías y paradigmas de desarrollo que jamás había utilizado, como lo son el lenguaje Swift y las aplicaciones mobile. De ambos solo conocía el nombre, pero jamas habia tenido tiempo de sentarme a crear algo en ese mundo. Hasta que un día surgió la oportunidad de formar parte del equipo que estaba desarrollando la app nativa iOS para uno de los bancos referentes del país, y de esta manera comenzó el desafío de desarrollar nativo en la plataforma Apple.
Luego de un tiempo ya habían pasado otros proyectos que me ayudaron a crecer en la programación de aplicaciones mobile y ampliar el espectro de lenguajes conocido a Objetive-C, con una sintaxis difícil de comprender inclusive el día de hoy.
Afortunadamente siempre estuve acompañado de un grupo de trabajo que podía ayudarme con las dudas técnicas y decisiones en el momento de hacer una mejora o plantear una solución.
Un nuevo reto
La app RedMob era el desafío en cuestión, de la cual solo se sabía que no estaba en producción, que se querían añadir nuevas funcionalidades y que era necesario reacondicionar. Una vez en contacto con el cliente (RedLink), comencé a tener un mejor panorama de la app y de las mejoras que hacía falta incorporar.
RedMob es una aplicación nativa tanto en Android como iOS, creada por RedLink para poder realizar pagos con tarjetas de crédito (para lo cual utiliza lectores de tarjetas).
Las metas
La aplicación nativa Android, por su parte, ya se encontraba en producción y se le estaban haciendo mejoras, por lo que los objetivos con su homóloga en iOS era que tenga las mismas funcionalidades. Para esto se requería:
- Parte 1: migrar de versión de Swift 2.3 a 3 y estabilizar la app.
- Parte 2: soportar nuevo dispositivo lector y agregar pantallas.
Parte 1: migración
Hasta ese momento, mis trabajos con Swift habían sido siempre con la versión 2.3. No había tenido oportunidad de desarrollar con Swift 3 y mucho menos de realizar una migración de código. La tarea no es complicada: Xcode hace gran parte del trabajo reemplazando las sentencias deprecadas por las nuevas, y marcando aquellos sitios en el código donde no puede realizar la migración. Es casi un proceso automático.
Lo arduo es reemplazar por nuevas sentencias aquellas en las que el IDE no supo cómo solucionarlo, y verificar que las que realizó de forma automática sigan ejecutando correctamente. Al momento de migrar código, Xcode solo corrobora que compile, pero no puede determinar si el algoritmo resultante realiza las misma tarea que el que fue sustituido.
Parte 2: nuevo dispositivo y pantallas
Una vez que la aplicación se ejecutaba, era momento de comenzar a refactorizar el código para poder añadir un nuevo dispositivo lector de tarjetas. Se recurrió entonces a desarrollar una interfaz que agregue una capa de abstracción entre la aplicación y los lectores de tarjetas para tener una forma común de utilizar los dispositivos. Obtener el estado, activar, desactivar, detectar el dispositivo y leer una tarjeta, ahora tenían una única forma de comunicación entre las funcionalidades de la app que requieren utilizar un dispositivo.
El primer paso estaba dado: se generó una interfaz con los métodos necesarios para poder operar desde la app con los dispositivos. Ahora quedaba reutilizar código empleado con el antiguo lector, adaptarlo a la interfaz, y por último, comprender cómo funciona el nuevo dispositivo, para desarrollar una clase que implemente la interfaz utilizando la librería del mismo
El camino estaba algo allanado. Para comprender cómo funcionaba el lector a integrar, se requirió ver cómo se interpretan los datos obtenidos de una lectura de tarjeta en la app de Android (afortunadamente, contaba con la ayuda de los desarrolladores). Por otro lado, era necesario leer la documentación y el código de la app-ejemplo provista por el fabricante (escrita en Objective-C), para poder finalmente integrar el nuevo lector a la interfaz.
Luego de algunas pruebas y correcciones en la integración, los lectores se encontraban funcionando. Sólo quedaba modificar dos pantallas, una de las cuales mostraba información de la aplicación, y en la que se agregaron los datos del dispositivo asociado. La otra pantalla (tal vez la más importante para la completar adaptación al nuevo lector), debía mostrar el reciente agregado modelo del lector en una lista con los dispositivos disponibles, lo que permitiría al usuario poder llevar a cabo la selección al momento de realizar operaciones con las tarjetas.
Después de un mes de trabajo finalmente la app estaba lista para pasar a las pruebas necesarias para corroborar que todo funciona como se espera.
Como en todo desarrollo siempre se suman nuevos conocimientos, puntos de vista y formas de trabajar. Este en particular, me ayudó a confiar en mí mismo y alistarme para nuevos desafíos. El reacondicionamiento de un producto digital, al igual que en los productos físicos, implica pruebas y una inspección exhaustiva, resultando en una mejora en la calidad. También implica paciencia y disposición a aprender.
