Aprendiendo Kotlin

Hola a todos!

Hace ya un mes que me cree el blog, y aún no me he atrevido a escribir ningún post.

Llevo ya bastante tiempo siguiendo a @lime_cl, y me interesé por Kotlin, el nuevo lenguaje que Antonio lleva tiempo explicando. Como bien os comenté en el primer post explicatorio sobre lo que iba a ir mi blog, os dije que estaba intentando aprender clean architecture y Dagger 2, así que, se me ocurrió crear un ejemplo con esto desarrollado en Kotlin.

El ejemplo se encuentra en Github, lo podéis obtener aquí. KotlinSeries

Además, tengo pensado desarrollar el mismo código en Java para poder comparar entre ambos lenguajes. Sería interesante observar el número de líneas que te ahorras usando Kotlin.

MVP

La estructura del proyecto está basada en MVP + Repository. El ejemplo muestra una lista de Series que se presentan ordenadas alfabéticamente. Por el momento está lista es rellenada por un fake, es decir, no hay conexión con ningún servidor ni DB, cosa que queda como objetivo para el futuro.

No voy a entrar en detalle de como se estructura el modelo MVP, ya que hay demasiado escrito sobre ello y al final del post os dejaré unas referencias muy interesantes. Pero sí os voy a contar como lo desarrollo yo.

Mis vistas, ya sean activity o fragment, siempre tienen un presenter. Llegado el caso que la vista tenga varias funcionalidades bien distintas, podría tener un presenter por cada funcionalidad. En el proyecto cada Activity tiene un presenter que se encarga de obtener notificaciones de la vista, y devolverle la contestación necesaria.

Cada activity suele tener una funcionalidad, que viene implementada por un caso de uso. La separación de estos casos de uso es estrictamente necesaria para mantener código limpio y fácilmente escalable. El caso de uso se encargará de solicitar al repository los datos que necesita.

En este test, como los datos son fake, no hay servidor, no aparece la función del ‘DataSource’, tema que abordaré cuando le incluya el servidor para descarga de datos.

El esquema sería el siguiente:

Kotlin vs Java

¿El post no iba de Kotlin?

Sí, en esta parte del post quería enseñaros las principales diferencias que he visto con Java.

Clases

Escribir clases con Java acaba siendo un verdadero coñazo, aunque con el generate… de Android Studio todo se simplifica. Sin embargo, las clases de objeto suelen definir varios setters/getters, además de un método equals o un toString.

En Kotlin vale con una línea para todo lo descrito anteriormente:

data class Serie(val name: String, val description: String, val image: String)

Hebras

En Java la descarga de datos se debe realizar en otra hebra que no sea la Main para no ralentizar la App. Por eso, se debe crear una nueva hebra, hacer la petición de descarga de datos, y una vez que se recibe la respuesta hay que volver a la Main Thread para mostrar los datos. En Kotlin el funcionamiento es el mismo, sólo que con bastante menos líneas de código.

fun getAll(callback : (ArrayList<Serie>?) -> Unit) {
        async() {
            var list = repository.getAll()
            uiThread {
                callback(list)
            }
        }
    }

Esto es posible gracias a la librería Anko.

Callback

Si alguno ha podido ver ya, el método anterior recibe como parámetro un callback. En Java para poder hacer esto era necesario crear una interfaz con un método, y implementarlo donde se llamara a la función. De nuevo, Kotlin elimina código innecesario y la llamada a getAll quedaría de la siguiente forma:

getSeries.getAll(){
    if(it?.size!!.compareTo(0) > 0){
        view?.hideLoading()
        (view as SeriesPresenter.View).showSeries(it)
    }else{
        view?.hideLoading()
        (view as SeriesPresenter.View).showEmptyCase()
    }
}

Cuando aparece la llamada a getAll no se le pasa ningún parámetro, aunque reciba el callback comentado anteriormente. Esto es porque el corchete que se abre seguidamente representa ese callback. La palabra reservada it sirve para recibir el parámetro, en este caso un ArrayList con las Series a mostrar.

Null Safety

Durante el código aparecen ? ó ! ó incluso !!. Gracias al operador ? nos salvamos de la archiconocida NullPointerException que tanta lata da.

Conclusión

Además de estas posibilidades comentadas, Kotlin ofrece otras muchas que aún no he tenido tiempo de investigar y probar.

Me decidí a probarlo por las grandes similitudes que vi con Swift, y he quedado impresionado con las posibilidades y la facilidad en el código. Como todo lo nuevo, supone una curva de aprendizaje al principio lenta, pero es un lenguaje que merece la pena conocer.

Creo que una de sus mayores virtudes podría ser la alternancia en el mismo proyecto de código Java y código Kotlin, ya que cada uno podría ser útil en un aspecto distinto o incluso para el uso de librerías con poca compatibilidad con Kotlin seguir usándolas en Java.

Espero seguir mejorando este ejemplo, y en posteriores post hablar sobre Dagger 2 y funcionalidades nuevas a implementar.

Referencias

Kotlin – Antonio Leiva – http://antonioleiva.com/kotlin/

MVP – Antonio Leiva – http://antonioleiva.com/mvp-android/

My way to clean Android – Christian Panadero – http://panavtec.me/my-way-to-clean-android/