¿Por qué en Urbvan migramos a Kotlin?

Hablar de desarrollo en Android es un tema con opiniones mixtas, incluso dentro de los desarrolladores de la misma plataforma. El ecosistema es amigable, aunque las herramientas suelen tener funcionamiento un tanto caótico. Es una experiencia “dulce” de cierto modo (si es que esto hace sentido).

Algo que siempre ha sido un let down del desarrollo en Android es utilizar lo que hasta 2017, fue su lenguaje oficial, Java.

En la conferencia I/O del 2017, Google nos dio la mejor noticia del año respecto al desarrollo en Android, Kotlin se convirtió en el nuevo lenguaje oficial para su desarrollo.

Google no se ha visto lento en la migración de Java a Kotlin. Desde mayo del 2017 los vídeos en su canal de Android Developers y los ejemplos de código, han cambiado a Kotlin, de igual forma, muchos de los ejemplos en su documentación oficial se están migrando.

Bueno, ¿Por qué a Kotlin?

A finales del año pasado, en Urbvan nos encontramos con una problemática. Añadir nuevas funciones a coste de perder compatibilidad con modelos de teléfono más viejos, o no agregar estas funcionalidades a coste de permitir estos modelos en nuestra base de usuarios. Parte de esta problemática se encontraba fuertemente atada a la tecnología utilizada, Java.

Cuando a principios de este año (2018), con la llegada de Android Studio 3.0, se terminó de oficializar el soporte a Kotlin, decidimos migrar la app desde cero en vez de ir migrando módulo a módulo. Esta decisión se tomó a partir de los siguientes fundamentos.

Urbvan no estaba bien 🤒

Las primeras versiones de Urbvan en Android no fueron creadas en casa, con el amor y dedicación que tenemos en el equipo de tecnología, sino que fueron creadas por una consultoría externa, y aunque el resultado entregado fue “bueno,” y que a partir de que se consolidó el equipo de desarrollo móvil se le fue dando mantenimiento, la arquitectura elegida para desarrollarla no fue la más óptima, y muchas veces los cambios en la lógica causaba más errores de los que se resolvían.

Mucha de esta lógica, creada por terceros, esperaba los mejores escenarios, y los errores más comunes que teníamos eran los famosos NullPointerException y dar mantenimiento a este tipo de errores se convirtió en una labor tediosa.

Kotlin al rescate. 🚑

Evitando los “errores del millon de dólares” 😒

Una de las filosofías más importantes de Kotlin, es la estabilidad del entorno en el que funciona. En Kotlin estos errores de núlabilidad no existen, y aunque pueden suceder, la forma de operatividad del lenguaje no te permite que aparezcan.

De la mano con esto, va que con Kotlin se logra más, escribiendo menos código. Dejaré un ejemplo muy claro a continuación:

https://gist.github.com/AlfredoBejarano/b774fb5589207748b15f0838fea4fb03

Explicando rápidamente, este método revisa si la sobrecarga object es nula, si es nula, ejecuta el método doFoo() en caso contrario, ejecuta doAnother().

Con Kotlin esto puede volverse mucho menos verboso (más legible) y con menos líneas, quedaría algo así:

https://gist.github.com/AlfredoBejarano/c1cf160912f478fe75e54dab0918c5de

Con este tipo de mejoras a la calidad de vida, el desarrollo se vuelve menos tedioso y más divertido, esto nos permitió aumentar nuestra productividad ya que, reiterando, se hace más con menos.

Escribiendo código inteligentemente. ¡yay! 🎉

Otra de las funcionalidades que trae Kotlin a la mesa son las funciones de extensión. Básicamente lo que hacen es añadir métodos a clases existentes sin tener que heredar de ellas o reescribirlas, utilizando la clase original.

Un ejemplo muy claro de esto sería en los Adapters de las RecyclerView que se usan comúnmente en Android, en Urbvan las utilizamos mucho. Cuando el adaptador crea una instancia del ViewHolder, se tiene que dibujar el contenido de éste, entonces se utiliza el método de la clase LayoutInflater, LayoutInflater.inflate()

https://gist.github.com/AlfredoBejarano/96da67e71756541b60b4be391c898b89

En cada adapter tendrías que escribir esto, y llamar al método inflate cada vez. ¿No sería mejor que la clase ViewGroup tuviera el método inflate? Con Kotlin es posible, y sería de esta forma:

https://gist.github.com/AlfredoBejarano/e1ac5a4f9a7a901feaf0808f851bcb23

por lo que ahora, en vez de llamar siempre a LayoutInflater.from(), puedes usar parent.inflate().

Solo hay que tener cuidado, ya que las funciones de extensión al momento de ser compiladas se convierten en funciones estáticas (static).

Mantenemos retro compatibilidad y funciones nuevas 😍

Muchas de nuestras funciones nuevas dependían de funciones y/o mejoras incluidas con Java 1.8, en Android esta versión de Java está atada a Android 5.0 Lollipop (API 21) y perdimos parte de nuestra base de usuarios que se encontraban en versiones anteriores, como KitKat.

Con Kotlin (incluso en la version 1.2.31 que es la que utilizamos), no existe una atadura de este tipo, ahora esta limitante viene de nuestras dependencias, por lo que podemos ir tan atrás, hasta Android 4.2 Jelly Bean (API 17).

Es simplemente más productivo

Aunque al final del día Kotlin se convierte a ByteCode, el compilado es mucho más rápido que el de Java, de igual forma el tiempo de ejecución y de procesamiento es más rápido en Kotlin que en Java, la sincronización con Gradle y las configuraciones del IDE son más rápidas con Kotlin, menos tiempo esperando y más tiempo programando.

Cerrando 🤔

Kotlin trajo muchas soluciones nuevas a problemáticas que había en el desarrollo de la aplicación en Android. Nos permite hacer código de forma más eficiente y nos quita ataduras que teníamos con Java.

Work smarter, not harder