¡BOOM! Sí, ha pasado, gracias al esfuerzo de la comunidad, Google ha dado un paso al frente y ha tomado, en mi opinión, una de las mejores decisiones que podía tomar.

Kotlin se convierte en lenguaje oficial para el desarrollo en Android

El anuncio se ha hecho hace muy poco en la Keynote de Google I/O 2017. Stephanie Saad Cuthbertson fue quién hizo los honores.

Aquí puedes ver el momento exacto del anuncio

¿Qué significa ésto?

Mucho. Muchísimo más de lo que en este momento se pueda pensar. Para empezar, la excusa (la principal excusa) de no dar el salto a Kotlin porque no está soportado por Google cae por su propio peso. A partir de ahora lo está y, además, viene directamente incluido en Android Studio 3.0. Por si ésto fuera poco, Google se compromete a dar soporte al lenguaje junto a JetBrains y ambos crearán una Fundación sin ánimo de lucro para el mantenimiento y evolución del lenguaje.

Kotlin no viene a sustituir a Java, viene a complementarlo y evolucionarlo. Parte de su éxito está en su total interoperabilidad con Java, haciendo que puedas usar Kotlin y Java simultáneamente sin preocuparte en posibles incompatibilidades. Ésto hace que cualquier proyecto, esté en el estado en el que esté, sea susceptible a incluir a Kotlin.

Hay que agradecer a toda la comunidad de Kotlin ya que el soporte oficial por parte de Google se ha convertido en realidad gracias a base de progresar juntos, compartir experiencias, hacer uso del lenguaje o, sobre todo, pedir a gritos al equipo de desarrollo Android que se fijaran en Kotlin como posible evolución de Java.

Ya no tienes excusa de pasarte a Kotlin, y por si aún tienes dudas o quieres saber más sobre Kotlin no dudes en leer mi post de mi mudanza a Kotlin si aún no lo has hecho 😊.

Links:

• Kotlin on Android FAQ
• JetBrains Announcement
• Official Kotlin Slack

Imagina que tienes el siguiente modelo para representar una carta de Póker:

enum class Suit {  
    HEARTS,
    SPADES,
    CLUBS,
    DIAMONDS
}

enum class Rank {  
    TWO, THREE, FOUR, FIVE,
    SIX, SEVEN, EIGHT, NINE,
    TEN, JACK, QUEEN, KING, ACE    
}

data class Card(val rank: Rank, val suit: Suit)  

Es un modelo muy sencillo, se compone de tres partes diferenciadas:

• Suit. Representa el palo de la carta (corazones, diamantes, tréboles o picas).
• Rank. Indica el valor de la carta (dos, tres, rey, as, etc.).
• Card. Una clase que contiene tanto el rank cómo el palo de la carta.

Para componer una carta simplemente hay que hacer:

val card = Card(Rank.QUEEN, Suit.HEARTS)  

Cómo la idea es facilitar la creación de una carta vamos a añadir una función llamada of al enumerado Rank:

enum class Rank {  
    TWO, THREE, FOUR, FIVE,
    SIX, SEVEN, EIGHT, NINE,
    TEN, JACK, QUEEN, KING, ACE;

    fun of(suit: Suit) = Card(this, suit)
}

¿Que hace of? Construye una carta a partir del propio Rank y del Suit recibido como parámetro. ¿Qué conseguimos? Añadir semántica a la creación de una carta, ejemplo:

val card = Rank.QUEEN.of(Suit.HEARTS)  

Podemos ir incluso un poco más allá y usar imports estáticos tanto para QUEEN como para HEARTS para conseguir que la creación de la carta sea más cercano al lenguaje natural:

val card = QUEEN.of(HEARTS)  

Mucho mejor ¿no?. Pues aún hay más, vamos a convertir la función of en una infix function. Para ello simplemente hay que añadir la palabra reservada infix al comienzo de la función:

enum class Rank {  
    TWO, THREE, FOUR, FIVE,
    SIX, SEVEN, EIGHT, NINE,
    TEN, JACK, QUEEN, KING, ACE;

    infix fun of(suit: Suit) = Card(this, suit)
}

¿Qué significa ser una infix function? Básicamente poder usarla con notación infix que, a grandes rasgos, es poder utlizar la función como si de un operador aritmético se tratara, es decir, usarla sin necesidad de escribir el punto y los paréntesis.

¿Cómo queda finalmente el uso de la función of? Te adelanto que super conciso:

val card = QUEEN of HEARTS  

Se podría decir que simplemente es syntactic sugar pero la realidad es que también nos ayuda a acercar muchísimo nuestro código al lenguaje natural, haciéndolo mucho más legible y conciso.

El fin de semana pasado se celebró el evento Freakend Mobile 2017. Es más una reunión de amigos que un evento dónde se juntan una muestra importante de la comunidad española desarrolladores Android e iOS.

¿Qué es el Freakend?

El Freakend es un evento informal organizado por Jorge Barroso dónde profesionales del sector para quedan para conocerse, charlar y, sobre todo, compartir experiencias y conocimiento. Normalmente nos juntamos en una casa rural pero este año se ha subido de nivel (debido a la alta demanda de asistencia) y la localización ha sido un pequeño hotel rural de la sierra de Madrid.

Lo mejor del Freakend, aparte de las magníficas charlas de los speakers, es el ambiente informal y las ganas de colaboración que hay entre todos los asistentes. Un sitio magnífico para consultar y aprender cómo trabajan otras compañeros y empresas del sector. Sinceramente, no se me ocurre un lugar mejor para hacerlo que en el Freakend con una cerveza en la mano (bueno, los que me conocen sabrán que en mi caso es un refresco).

Fotos de 47 Degrees

Charlas

El repertorio de Speakers, como es habitual, de un gran nivel comenzando, cómo no puede ser de otra forma, con una keynote que este año fue llevada por David González (GDE). Después tuvimos una mesa redonda sobre trabajo en remoto y sus diferentes formas, mencionar la envidia que personalmente tuve de Enrique López cuándo comentó como trabaja en remoto de forma nómada habiendo trabajando desde más de 30 países diferentes en 2016, ¡increíble!.

El día siguiente fue una jornada repleta de charlas geniales comenzando con la máster class de Raúl Raja como es ya habitual en todas sus intervenciones. Inmediatamente después habló un servidor 😊. El día se completó con las charlas de Cristian Monforte de Xing, Alberto Ballano también de Xing, Raúl Hernández, los Karumis Davide y Pedro, Pedro Piñera de SoundCloud, Hugo Matilla de Scondoo, Sergio Padrino con su divertísima charla de Plex, Javi Pacheco y el espectáculo hecho persona con Fernando Franco y su curso de Sketch en directo.

El domingo se cerró el evento con las intervenciones de Luis Ascorbe de Wallapop y del gran Pablo Guardiola recién incorporado a Mapbox.

Mi charla

Ya había dado alguna charla anteriormente pero siempre a nivel interno dentro de Telefónica, así que se puede decir que es la primera vez que hablo de forma pública y, sobre todo, ante unos asistentes con tal nivel de experiencia y conocimiento. Espero haber dado el callo.

Los chicos de Autentia se pegaron la gran currada de grabar y montar todas las charlas para que los que no pudieron asistir puedan disfrutarlas de igual manera. Podéis encontrarlas aquí.

En mi caso, soy un fan aférrimo de las charlas dónde alguien nos cuenta como solucionó un problema real al que tuvo que enfrentarse, comentando los pasos a seguir, las soluciones adoptadas y sus porqués. En mi opinión, son de las que se aprenden más.
Ese fue mi caso, el año pasado tuvimos una necesidad en la aplicación de TU de iOS dónde quisimos abordar un refactor importante mejorando la forma en que sincronizábamos los datos de la aplicación con backend. De esa experiencia nació esta charla: Extensible Synchronization Layer using Core Data.

Conclusión

Como todos los años, una gran experiencia dónde siempre se aprende algo nuevo. No encuentro una mejor manera de resumirlo que con este tweet de Saúl:

Si en el #freakendmobile no vuelves con ideas para implementar nada mas volver; you're doing it wrong.

— Saúl Díaz González (@sefford) 20 de febrero de 2017

Así ha sido mi caso, muchas ganas de intentar a empezar a usar representaciones algebráicas para los modelos de mi aplicaciones incluyendo los casos de error que el dominio debería controlar (gracias a Raúl Raja) o empezar organizar mejor los recursos Android de mis aplicaciones basándome en la experiencia personal que compartió David González, y ésto son sólo algunos ejemplos de lo que aprendí.

La parte negativa es la poca representación de mujeres que había, no las conté pero creo que habría unas 4 o 5 únicamente. Desgraciadamante, ésto viene siendo una tónica habitual en eventos tecnólogicos pero estoy seguro que no es el porcentaje real de representación femenina del sector y espero que poco a poco se vayan animando a participar ya que éstos eventos van sobre personas desarrolladoras, sin importar género o experiencia.

Como te hablé en mi post sobre por qué empecé a usar Kotlin, una de las funcionalidades más útiles que nos provee Kotlin es la habilidad de crear extensiones a clases de las cuáles no necesitamos tener acceso a su código. Lo vas a entender mejor con un ejemplo.

Imagina el siguiente helper escrito en Java

public static boolean isWeekend(Date date) {  
   Calendar calendar = Calendar.getInstance();
   calendar.setTime(date);
   int dayOfWeek = calendar.get(Calendar.DAY_OF_WEEK);
   return dayOfWeek == Calendar.SATURDAY || dayOfWeek == Calendar.SUNDAY
}

Es una función estática pura que recibe como parámetro la fecha en la que queremos comprobar si es fin de semana o no. En Java, este método estático tiene que estar dentro de una clase, vamos a suponer que se llama DateUtils por lo que para usarlo necesitas hacer lo siguiente:

boolean isWeekend = DateUtils.isWeekend(myDate);  

Para evitar este tipo de métodos estáticos Kotlin provee un mecanismo para añadir funcionalidad a clases que no tenemos acceso: Extensiones. La idea es añadir un método llamado isWeekend() a cualquier objeto de tipo Date. Para ello, simplemente hay que declarar la función de una forma concreta:

1. fun Date.isWeekend(): Boolean {  
2.   val calendar = Calendar.getInstance()  
3.   calendar.time = this  
4.   val dayOfWeek = calendar.get(Calendar.DAY_OF_WEEK)  
5.   return dayOfWeek == Calendar.SATURDAY || dayOfWeek == Calendar.SUNDAY  
6. }  

La sintaxis es muy simple. Se tiene que indicar el nombre de la clase la cuál se quiere extender su funcionamiento, punto y el nombre del método. A partir de ese momento, en el cuerpo de la función tenemos acceso a this que es un puntero al objeto dónde se ha llamado el método. Fíjate como en la línea número 3 se usa this como la fecha en la que queremos calcular el día de la semana ya que no se recibe ninguna fecha como argumento de la función.

¿Cómo se usaría? Muy fácil, simplemente llamando al método en cualquier objeto de tipo Date:

val isWeekend = myDate.isWeekend()  

Sencillo ¿no? 😊

Fragment Manager

Te voy a enseñar otro ejemplo, esta vez enfocado a Android.

Para darte un poco de contexto, en Android cuándo se quiere por ejemplo reemplazar un Fragment es necesario crear una transacción a través del objeto FragmentManager. Ejemplo:

val fragmentTransaction = fragmentManager.beginTransaction()  
fragmentTransaction.replace(R.id.container, newFragment)  
fragmentTransaction.commit()  

Es una de las transacciones de Fragments más básicas que existe pero es ideal para ilustrar el ejemplo. Si te fijas la transacción se divide en tres partes bien diferenciadas:

• Inicialización
• Cuerpo de la transacción
• Finalización

// Initialising transaction
val fragmentTransaction = fragmentManager.beginTransaction()

// Transaction body
fragmentTransaction.replace(R.id.container, newFragment)

// Committing transaction
fragmentTransaction.commit()  

¿Cómo sería la extensión entonces? Añadiríamos un nuevo método a FragmentManager que recibe una lambda o función dónde detallaremos las operaciones a realizar en la transacción. Además, está función recibirá como argumento la transación dónde realizar las operaciones:

fun FragmentManager.executeTransaction(operations: (FragmentTransaction) -> Unit) {  
   val transaction = beginTransaction()

   transaction.operations()

   transaction.commit()

}

Puede parecer muy complicado pero ahora cuándo veas cómo se usa verás que realmente es más sencillo de lo que parece:

fragmentManager.executeTransaction { transaction ->  
   transaction.replace(R.id.container, fragment)

}

Sencillo. Simplemente llamar al nuevo método con una lambda detallando las operaciones a realizar, en este caso un replace().

¿Ventajas? De esta manera, aparte de ahorrar boilerplate al tener que escribir beginTransaction()
 y commit() cada vez te asegura qué no te vas a olvidar de commitear la transaccion al final, de esta manera consegues que tu código sea mucho más robusto.

Bonus

Hasta aquí lo básico sobre extensiones pero por si te has quedado con ganas de más voy a enseñarte como mejorar aún más esta función de extensión.

Para empezar, te puedes ahorrar escribir transaction en la cabecera de la lambda usando la palabra reservada it. A modo de resumen, it hace referencia al argumento de una lambda cuándo sólo hay un único argumento.

fragmentManager.executeTransaction {  
   it.replace(R.id.container, fragment)

}

Queda mucho más limpio ¿verdad? Pues aún se puede hacer más. Recuerda cómo se pasa como argumento la transacción dódne ejecutar las operaciones a la función que recibe executeTransaction. Ahora, ¿y sí en vez de pasar la transacción como argumento haces que dicha función sea una extensión de FragmentTransaction? Pues dicho y hecho:

fun FragmentManager.transaction(operations: FragmentTransaction.() -> Unit) {  
   val transaction = beginTransaction()

   transaction.operations()

   transaction.commit()

}

La diferencia simplemente es que ahora dentro de la lambda de operaciones no hay que referirse de ninguna manera a la transación ya que la función se está ejecutando dentro de la transación en sí:

fragmentManager.executeTransaction {  
  replace(R.id.container, fragment)

}

Eso es todo. Esta última parte puede parecer un poco más complicada pero realmente es más sencillo de lo que parece, al final el principio es el mismo: cualquier clase puede ser extendida con métodos o funciones nuevas.

Si tienes cualquier duda o sugerencia no dudes en hacédmela llegar, estaré encantado en intentar resolverla.

Antes de nada, quiero que sepas que llevo desarrollando en Java desde hace más de 10 años por lo que he seguido su evolución muy de cerca. Java, aunque muy lentamente, va evolucionando añadiendo características que poseen lenguajes más modernos como puede ser opcionales, lambdas o streams.
El problema está en que su ritmo de evolución es demasiado lento y, además, están obligados a preservar su verbosidad intrínseca haciendo que muchas de las nuevas características no sean tan agradables de usar como debieran.

Kotlin

Kotlin es un nuevo lenguaje desarrollado por JetBrains. Por si no los conoces son los creadores de, en mi opinión, los mejores IDEs del mercado: IntelliJ / Android Studio, AppCode, ReSharper o Rider.

Kotlin es un lenguaje de tipado estático que compila a bytecode de la máquina virtual de Java (JVM) o incluso a JavaScript. Ésto quiere decir que puede usarse en cualquier sitio donde haya una JVM ejecutando bytecode. Personalmente, considero que viene para reemplazar a Java en aquellos lugares dónde usar otros lenguajes basados en JVM son inviables de usar o demasiados grandes añadiendo muchos nuevos métodos en sus librerías.

A diferencia de otros lenguajes como puede ser Scala que viene del sector académico, Kotlin viene de la industria (de JetBrains cómo te mencioné antes) con un periodo de diseño, iteración y desarrollo muy largo para convertirlo en un producto muy maduro desde su primera versión estable, con el objetivo de resolver problemas que a día de hoy tenemos todos los programadores de Java.

Otro de los objetivos importantes en su diseño es que sea 100% compatible e interoperable con Java: ejecutar código Java desde Kotlin o viceversa (código Kotlin desde Java) sin problemas. ¿Qué quiere conseguir JetBrains con ésto? Dos cosas:

1. Minimizar la barrera de entrada permitiendo que, por ejemplo, no tengas que esperar a desarrollar un nuevo producto para empezar a utilizarlo sino que puedas empezar a utilizar Kotlin en todo nuevo código que desarrolles sin tener que preocuparte por la compatibilidad.
2. Tener a tu disposición cualquier librería y/ framework escrito en Java disponible actualmente desde el primer día.

Por si esto fuera poco Kotlin no es solo un lenguaje, sino que es una dupla de lenguaje y plugin para diferentes entornos de desarrollo. Entre las características que ofrece está el auto-completado, soporte completo para depuración, refactors e incluso un convertidor de Java a Kotlin. El plugin está disponible (en el momento de escribir este post) para todos los IDEs más usados:

• Android Studio
• IntelliJ
• Eclipse
• Netbeans

Características

Voy a empezar enseñándote un simple ejemplo para que veas la diferencia de verbosidad entre Java y Kotlin:

El típico POJO de, en este caso, 3 campos que en Java ocupa 24 líneas en Kotlin es simplemente una 😍.

No quiero enrollarme mucho contando las bondades de Kotlin, porque no son pocas y quedaría un post muy largo, así que voy a detallar las que considero que son las más importantes:

• OpenSource con una comunidad muy viva.
• Sintaxis clara y concisa, quita toda la verbosidad intrínseca de Java. Puede ser aprendido en cuestión de horas.
• Opcionales. Adiós a NullPointerException. Algo puede ser null únicamente si indicas que puede serlo.
• Inferencia de tipos. Es decir, dejamos al compilador que sea capaz de inferir los tipos que estoy usando y me ahorre declaralos de antemano. Ej.: val text = “Hola”
• Data classes. Autogeneración de boilerplate para POJOs (getters/setters, hashCode, equals, toString, etc.).
• Extensiones. Di adiós a las clases Utils. Permite añadir nuevos métodos a clases sin necesidad de tener acceso a ellas. Te hablaré sobre ellos en próximos posts 😉.
• Funcional. Soporte para Programación Funcional.
• Inmutabilidad por defecto. Contra menos variables mutables tengas más seguro será tu programa, sobre todos en entornos multithreading. Kotlin te ayuda e incentiva a que utilices tantos datos inmutables como sea posible.
• Operadores. Añade soporte a tus clases de operadores como +, -, *, etc. Por ejemplo, Kotlin añade operadores a las colecciones básicas de Java por lo que puedes sumar dos listas de forma sencilla: val newList = list1 + list2, ésto devolverá una nueva lista con el contenido de ambas listas.
• Sealed Classes. Los enum del futuro. Escribí sobre ellos aquí.
• Propiedades Lazy. Propiedades que inicializan su valor cuando, por ejemplo, son usadas por primera vez.
• Compila a Java 1.6. Éste es el GRAN punto para los desarrolladores Android como yo 😉.

¿Porqué uso Kotlin?

Android nació con soporte para Java 1.6 (lanzado en 2006) añadiendo soporte casi completo para Java 1.7 más adelante, digo casi completo porque hay cosas como Try with Resources que sólo es soportado desde KitKat (API Level 18).
Hace muy poco se añadió soporte para Java 1.8 que trae soporte para características modernas como Lambdas, Method References o Type Annotations. La pega es que sólo están disponibles si tu aplicación soporta dispositivos desde Marshmallow (API Level 23) hacia arriba, haciéndolo inservible a día de hoy porque normalmente queremos abarcar el máximo dispositivos posibles cuando desarrollamos una aplicación.

Resumiendo, en Android estamos desarrollando en una especie de Java 1.65, es decir, usando herramientas que se lanzaron ¡hace más de 10 años!. Afortunadamente, ahora tenemos la posibilidad de usar Kotlin que viene a resolver muchos de éstos problemas.

Como te dije antes, Kotlin compila a bytecode de Java 1.6 por lo que es compatible con todos los dispositivos Android. Aún usando bytecode antiguo es capaz de darnos características modernas (algunas que empieza a traer Java 8) como puede ser Lambdas o Opcionales y, además, ser capaz de seguir evolucionando el lenguaje con cada nueva versión (ofreciendo retrocompatibilidad).

Desde el punto de vista de desarrollador Android puro Kotlin está perfectamente integrado con el ecosistema. Tiene soporte total con Android Studio y, además, incluye plugins y librerías adicionales para ayudarnos en el día a día del desarrollo en Android (Anko o Kotlin Android Extensions, hablaré sobre ellos en el futuro).

El soporte que está brindando JetBrains es espectacular, responden con mucha rapidez a cualquier problema y, además, tienen un Slack oficial sobre Kotlin dónde cualquiera puede resolver sus dudas casi instantáneamente. Es muy activo. Lo recomiendo 100%.

Existen otras alternativas a Java para desarrollar aplicaciones en Android sobre JVM como puede ser Scala, pero en mi opinión son muy pesadas y las herramientas disponibles para Android no están al nivel de lo que ofrece Kotlin desde el primer día.

¿Quién está usando Kotlin?

Aquí puedes ver algunas productos y empresas que ya están usando Kotlin:

Un montón de grandes empresas ya han confiando en Kotlin para sus productos por lo que, en mi opinión, Kotlin no es el futuro sino el presente.

Conclusión

Sinceramente, no veo razón ninguna para seguir anclado a Java teniendo a nuestra disposición un lenguaje como Kotlin que en el caso de tener algún problema o incompatibilidad (aún no me he encontrado con ninguno) poder escribir en Java esa parte sin problema.

Espero haberte convencido, tanto si es así como sino te animo a que le des una oportunidad al lenguaje y pruebes sus bondades de primera mano 🙂.

Una de las mejores formas de trabajar mejor es teniendo bien organizado tu proyecto, y no, no me refiero únicamente al código de tu aplicación sino también al de tus dependencias.

Es muy común, por lo menos en mis primeros proyectos con Gradle, tener todas las dependencias a cascoporro sin llevar ningún tipo de control de versiones o, simplemente, de agrupación de tipo de dependencias. Para evitarlo, intento sacar todas las dependencias a un fichero común dónde intento organizarlas de una forma más concisa y legible.
Eso es lo que te traigo hoy, un videotutorial de cómo organizo las dependencias de mis proyectos Android con Gradle.

Aquí te dejo el Pull Request de los cambios que he hecho al proyecto y, también, el fichero dependencies.gradle de mi proyecto Openticator dónde puedes ver un ejemplo más completo de esta organización sobre un proyecto real.

Y tú, ¿a qué esperas para organizar tus ficheros gradle con lo que has aprendido? No dudes en compartir conmigo los resultados 😊.

Poco antes de terminar el pasado año, JetBrains lanzó su última versión de Kotlin y entre otras novedades han añadido un plugin muy interesante: All-open plugin.

Introducción

Antes de explicar qué es exactamente, me gustaría recordarte que por defecto todas las clases son finales en Kotlin a no ser que indiquemos lo contrario usando la palabra reservada open:

open class HelloWorld {  
}

¿Qué significa ésto? Que si no indicas que una clase es open no podrás heredar de ella ni sobreescribir ningún método ya que es una clase final.

Desde el punto de vista de programador ésto no debería ser un problema, de hecho yo considero una ventaja que nadie pueda heredar de mis clases para cambiar su comportamiento si no está explícitamente especificado para ello con open.

En cambio, ésto sí es en un problema cuándo necesitas que algunas de tus clases y todos sus miembros sean open explicítamente por requerimientos del framework, como puede ser, por ejemplo, cuándo usas @Component o @Bean en Spring, o cuándo estás creando un nuevo modelo para la base de datos Realm.

¿Qué es?

All-Open Plugin es un nuevo plugin introducido en Kotlin 1.0.6 que nos permite convertir clases con todos sus miembros a no finales sin tener que escribir la palabra reservada open manualmente.

¿Cómo funciona?

Imagina que tenemos un DataStore que se utiliza como punto de entrada en nuestro código para escribir y leer información sin importarnos dónde lo hace realmente. Ejemplo:

class SimpleDataStore {  
   fun read(): String {
      // read something
   }
   fun write(val data: String) {
      // write data to somewhere
   }
}

Si queremos que esta clase se convierta en no final simplemente tenemos que decirle al plugin que queremos que haga su trabajo en nuestra clase. ¿Cómo se hace? A través de anotaciones, para ello necesitamos crearnos una anotación que usaremos para anotar las clases que queremos que se openicen (puede tener cualquier nombre, yo la he llamado AllOpen por simplicidad):

package com.arturogutierrez.example

annotation class AllOpen  

Ahora, necesitamos anotar nuestro DataStore con @AllOpen:

@AllOpen
class SimpleDataStore {  
   fun read(): String {
      // read something
   }
   fun write(val data: String) {
      // write data to somewhere
   }
}

Desde el punto de vista de código hemos terminado, sólo nos queda activar el plugin en nuestro proceso de build. Para ello, necesitamos añadir la dependencia en nuestro build script. Abre el fichero build.gradle de tu proyecto y añade el plugin a dependencies:

buildscript {  
  dependencies {
    classpath "org.jetbrains.kotlin:kotlin-allopen:1.0.6"
  }
}

Ahora abre tu fichero build.gradle de tu aplicación, depende de la configuración de tu proyecto puede ser el mismo o no, en el caso de Android solemos tener un build.gradle para el proyecto y otro por módulo por lo que ahora tienes que abrir el perteneciente al módulo, y añade el nuevo plugin con su configuración:

apply plugin: 'kotlin-allopen'

allOpen {  
    annotation("com.arturogutierrez.example.AllOpen")
}

Cómo habrás visto no sólo tenemos que añadir el plugin sino que además tenemos que indicarle que anotación va a usar para buscar las clases que queremos que se conviertan en no finales.

Si quieres usar varias anotaciones en vez de una sólo no hay problema, el plugin también incluye la propiedad annotations (nótese el plural) dónde puedes pasar una lista de anotaciones:

allOpen {  
    annotations("com.arturogutierrez.example.AllOpen", "com.arturogutierrez.example.AllOpenAgain")
}

¡Eso es todo!, ahora cada vez que compiles las clases serán abiertas automáticamente en tiempo de compilación sin que tengas que hacer nada más 🙂.

Ejemplo Real

Si has trabajado con Realm para Android sabrás que cuándo creas un modelo éste no puede ser final para que Realm pueda hacer su magia en tiempo de compilación. Ésto en Java no es un problema porque por defecto todo es no final, en cambio, en Kotlin es al revés, todo es final a no ser que digas que no lo es explícitamente con open.
En el caso de Realm es tedioso (y además feo) tener que poner todo open manualmente por lo que ésto es un caso de uso perfecto para el plugin.

Voy a poner un caso real de mi aplicación Openticator que estoy desarrollando. Tengo un modelo de Realm que describe la cuenta de un usuario de ésta manera:

open class AccountRealm : RealmObject() {  
  @PrimaryKey
  open var accountId: String = ""
  open var name: String = ""
  open var type: String = ""
  open var secret: String = ""
  open var issuer: String = ""
  open var order: Int = 0
  open var category: CategoryRealm? = null
}

Como ves, todo es open para que Realm funcione correctamente. ¿Qué he hecho entonces? Crearme una anotación que he llamado RealmModel para anotar mis modelos con ella y decirle al plugin que use la anotación para convertirlas en open:

@RealmModel
class AccountRealm : RealmObject() {  
  @PrimaryKey
  var accountId: String = ""
  var name: String = ""
  var type: String = ""
  var secret: String = ""
  var issuer: String = ""
  var order: Int = 0
  var category: CategoryRealm? = null
}

Podemos decir que este caso de uso es el caso de uso perfecto para usar este nuevo plugin. Si estás interesado en ver exactamente los cambios que he hecho en la aplicación para usar el plugin puedes ver consultar Pull Request en GitHub.

Limitaciones

Una vez que añades el plugin a tu bulid script no puedes activar o desactivarlo por configuración, lo que sería muy interesante para testing. Por ejemplo, sería muy interesante crearse una anotación @OpenForTesting y aplicar el plugin sólo para testing, sin modificar las clases fuera del ámbito de testeo.

La razón de querer hacer ésto es que no se pueden mockear clases finales (de una forma sencilla), entonces, si quieres mockear una dependencia de la clase que estás testeando y esa dependecia es final probablemente termines haciéndola open o extrayendo una interfaz (cuándo sólo tienes una implementación y no tiene sentido extraer una interfaz para una sola clase en la mayoría de los casos).

Es cierto que ahora con Mockito 2 se pueden mockear clases finales pero el soporte es experimental y, además, es incompatible con el resto de test frameworks que modifiquen bytecode cómo puede ser Robolectric.

Eso es todo, a partir de aquí sólo queda que lo pruebes, experimentes, que busques casos de uso dónde más te cuadre y nos cuentes la experiencia 😊.

El comienzo de año es el típico momento dónde solemos dar un paso atrás para pararnos a pensar en dónde estamos, qué estamos haciendo y, no menos importante. qué podemos hacer.
Eso hice y me di cuenta qué quiero empezar a hacer cosas que hasta hace unos meses no me planteaba ni hacer.

Ponerse objetivos no es más que un ejercicio de planificación de lo que se quiere conseguir durante el año. No es obligatorio hacerlo pero si no lo haces, probablemente, pierdas el rumbo en algún momento y termines viendo cómo pasan los días y meses sin darte cuenta sin haber conseguido mucho o nada de lo que te planteaste.

Con ese ejercicio de pararse a pensar es cómo ha nacido éste blog. Antes tenía posts sueltos escritos en inglés pero me he dado cuenta que quiero cambiar el target, quiero enfocarme en la comunidad castellanoparlante qué, por cierto, no tiene nada que envidiar a las demás, creo que es una comunidad suficientemente grande y madura y dónde además creo que puedo aportar 😊.

Objetivos 2017

• Blog. Comenzar o migrar mi blog a Español y empezar a escribir con asiduidad. El objetivo es conseguir al menos 500 usuarios únicos.

• Facebook. Crear una página de Facebook como soporte al blog dónde potenciar mi marca personal y conseguir un mínimo de 100 likes.

• YouTube. Crear un canal de YouTube dónde subir videotutoriales o cursos de las tecnologías que estoy acostumbrado a trabajar. Mi idea es intentar llegar a 100 suscriptores a final de año.

• Curso Online. Me gustaría lanzar un curso online sobre Android, Kotlin o Unity 2D en Udemy o similar. Creo que es una plataforma con mucho potencial y dónde puedo aportar valor también.

• Libro. Siempre se dice que en la vida hay que hacer tres cosas: "escribir un libro, plantar un árbol y tener un hijo". Árbol e hijo ✅ así que me falta el libro para estar completo. Realmente siempre he querido escribir un libro así que este año me propongo como objetivo comenzar a escribir un libro técnico.

La verdad es qué son objetivos muy ambiciosos pero quiero que este año 2017 sea un año importante para mí desde el punto de vista profesional y, al menos, conseguir poner los primeros ladrillos a mi marca personal. Veremos qué nos depara este excitante 2017 🙂.

Últimamente, he estado desarrollando en Swift por motivos de trabajo y, para ser sincero, me encantan los enumerados con datos asociados de Swift. Si no sabes lo que es, no te preocupes, veremos ejemplos pero te puedo asegurar que luego no podrás vivir sin ellos.

Normalmente, un enum (enumerado) puede contener información, pero el tipo tiene que ser el mismo para todos los casos. Ejemplo:

public enum DayOfWeek {  
   MONDAY(1),
   TUESDAY(2),
   WEDNESDAY(3),
   THURSDAY(4),
   FRIDAY(5),
   SATURDAY(6),
   SUNDAY(7);

   private int dayNumber;
   private DayOfWeek(int dayNumber) {
      this.dayNumber = dayNumber;
   }
   public int getDayNumber() {
      return dayNumber;
   }
}

Mismo código en Kotlin (mucho más bonito):

enum class DayOfWeek(val dayNumber: Int) {  
  MONDAY(1), TUESDAY(2), WEDNESDAY(3), THURSDAY(4),
  FRIDAY(5), SATURDAY(6), SUNDAY(7)
}

Los enumerados de Java no soportan diferentes tipos de valores por cada enum por lo que no podemos tener algo como esto:

   MONDAY(1),
   TUESDAY(2),
   WEDNESDAY(3),
   THURSDAY(4),
   FRIDAY(5),
   SATURDAY("WEEKEND"),
   SUNDAY("WEEKEND");

Lo sé, es un ejemplo un poco extraño, pero creo que es suficiente para entender cuál es la limitación en los enumerados de Java, ¿verdad?

Ahora, imagina que estás al cargo del desarrollo de una nueva aplicación de mensajería instantánea y estás trabajando en el diseño del modelo de todos los tipos que una conversación puede tener (aka Eventos):

• Mensajes de texto
• Imágenes
• Mensajes de voz

Obviamente, existen varias propiedades en común para todos los tipos:

• Fecha del evento
• Sí es entrante o saliente
• Estado de entrega, etc.

Quizá, tu primera aproximación sería crear una clase base llamada Event para empezar a crear subclases por cada tipo de evento. No pasa nada, yo probablemente hubiese hecho lo mismo pero, ¿y si te digo que hay una mejor forma de modelarlo usando enumerados con diferentes tipos de datos asociados? Suena bien, ¿verdad?

La idea es usar el poder de los datos asociados de los enumerados. Realmente, esto no se puede hacer en Kotlin directamente porque al ser un lenguaje que hereda de Java posee las mismas limitaciones en los enumerados pero los chicos de JetBrains ya pensaron en ello, añadieron una característica llamada Sealed classes en Kotlin que emula todo lo que hemos hablado directamente, de hecho los consideran como el reemplazo de los enumerados estándar de Java.

En vez de explicar que es una Sealed classes mostraré un ejemplo, para ser más exactos un ejemplo de la propiedad DeliveryStatus. La idea es almacenar el estado de un evento por lo que podemos tener tres posibilidades:

• Entregado
• Entregando.
• NoEntregado. Éste es un caso especial porque queremos almacenar el mensaje real de error para poder mostrárselo al usuario en la aplicación.

Usando una sealed class llamada DeliveryStatys lo modelaríamos de la siguiente forma:

sealed class DeliveryStatus {  
    class Delivered : DeliveryStatus()
    class Delivering : DeliveryStatus()
    class NotDelivered(val error: String) : DeliveryStatus()
}

Esta clase sellada actuan como un enum realmente porque no puede ser extendida y cada "clase interna" actua como un caso de enumerado, de esta forma puedes definir los datos asociados por cada caso individualmente. Puedes leer más (no mucho más realmente) sobre ellos en Kotlin Docs.

Seguimos, dirección del evento:

• Entrante. Debe incluir el remitente envío el evento,
• Saliente. Debe incluir el estado de entrega que hablamos anteriormente.

sealed class Direction {  
    class Incoming(val from: String) : Direction()
    class Outgoing(val status: DeliveryStatus) : Direction()
}

Ahora, modelaremos el tipo de evento, recuerda que tenemos tres tipos de eventos: Menajes de Texto, Imágenes y Notas de Voz.

sealed class ContentType {  
    class Text(val body: String) : ContentType()
    class Image(val url: String, val caption: String) : ContentType()
    class Audio(val url: String, val duration: Int) : ContentType()
}

Fíjate como cada tipo de evento tiene su propio tipo de dato asociado: el cuerpo para los mensajes, URL y título para las imágenes y URL y duración para las notas de voz.

Finalmente, sólo nos queda crear la clase que define el contenido de un evento completo:

data class Event (val contentType: ContentType, val direction: Direction)  

Para ser un poco más claro aquí tienes un ejemplo de como usar este modelo:

// An event list example but this could be retrieved from a Conversation data store in a real app
val events = listOf(  
    Event(ContentType.Text("Hey, I'm Tony"), Direction.Incoming("Tony Stark")),
    Event(ContentType.Image("URL_TO_IMAGE", "Avengers"),  Direction.Incoming("Bruce Banner")),
    Event(ContentType.Audio("URL_TO_AUDIO", 15), Direction.Outgoing(DeliveryStatus.Delivered()))
)

for(event in events) {  
    renderEvent(event)
}

fun renderEvent(event: Event): Unit {  
    when(event.contentType) {
        is ContentType.Text -> println("${event.contentType.body}")
        is ContentType.Audio -> println("Audio of ${event.contentType.duration} secs.")
        is ContentType.Image -> println("Image (${event.contentType.caption})")
    }
}

Fíjate cómo event.contentType es casteado dentro de la cláusucla is, ésto nos permite acceder sus campos específicos en tiempo de compilación sin necesitas de hacer el casteo a mano (Kotlin ❤️ ).

Eso es todo, hemos modelado nuestros eventos usando clases selladas, pero además, esto nos ofrece aún más beneficios:

• El compilador conoce cuántos tipos de la clase sellada hay por lo que la sentencia when es capaz de detectar si falta algún caso en tiempo de compilación.
• Todos los eventos son inmutables.
• Todo es mucho más claro y conciso.

Si estás interesado en jugar con el código fuente de ejemplo puedes hacerlo en Try Kotlin.

Para terminar, simplemente añadir que este tipo de modelado se está usando en la versión de iOS de Movistar TU que está escrita en Swift. Estamos muy contentos con el resultado ya que hemos conseguido que todo sea más legible y conciso y le hecho de poder hacer lo mismo en Android con Kotlin nos abre un montón de puertas nuevas.

Hoy, me he estado pegando con el problema de cómo aceptar de antemano el certificado autofirmado que tiene el servidor del trabajo cuándo estás clonando un repositorio Git usando una URL HTTPS.
El tema está en que si intentar clonar un repositorio que está en hosteado en una máquina con un servidor autofirmado obtendrás el siguiente error:

$ git clone https://www.myserver.com/myrepo.git
fatal: unable to access 'https://www.myserver.com/myrepo.git/': SSL certificate problem: Invalid certificate chain  

Git no pregunta si quieres aceptar el certificado por lo que no se puede acceder al contenido si no nos saltamos la verificación SSL que lleva.

Probablemente te estarás preguntando porque no uso una conexión SSH para clonar el repositorio ¿no?. Por motivos que no vienen al caso no puedo usar conexión SSH y necesito acceder al respositorio por HTTP.

La primera opción que encontré es deshabilitar la verificación del certificado cuando clono el repositorio:

GIT_SSL_NO_VERIFY=true git clone https://www.myserver.com/myrepo.git  

Funciona pero no es nada trivial (a vece imposible) añadir el flag GIT_SSL_NO_VERIFY en todos los comandos git cuándo el problema lo tiene la máquina de integración continua o, como es mi caso, cuándo estás usando CocoaPods.

Forma insegura

La forma más fácil de solucionarlo es decirle a Git que no verifique ninguna conexión SSL en todos los repositorios:

git config --global http.sslVerify false  

Por favor, NO LO HAGAS o te cargarás de un plumazo toda la seguridad que ofrece HTTPS.

Forma segura

Resumen:

1. Descargar el certificado autofirmado.
2. Decir a Git que confíe en ese certificado.

Descargar el certificado autofirmado.

Si tienes openssl instalado lo puedes hacer de forma muy sencilla:

openssl s_client -connect myserver.com:443  

Captura la respuesta y crea un fichero con sólo el contenido entre las lineas BEGIN CERTIFICATE y END CERTIFICATE (ambas incluídas) y renómbralo a, por ejemplo, certificate.pem. Debe quedar algo así:

-----BEGIN CERTIFICATE-----
MIIGMDCCBRigAwIBAgIKGpFzcgADAABKojANBgkqhkiG9w0BAQUFADA/MRQwEgYK  
CZImiZPyLGQBGRYEaW5ldDESMBAGCgmSJomT8ixkARkWAmhpMRMwEQYDVQQDEwpJ  
U1NVRUNBVElEMB4XDTE1MDYwMzA2MTY1NFoXDTE3MDYwMjA2MTY1NFowZzELMAkG  
A1UEBhMCRVMxCzAJBgNVBAgTAk1BMQ8wDQYDVQQHEwZNYWRyaWQxEzARBgNVBAoT  
ClRlbGVmb25pY2ExDDAKBgNVBAsTA1RpRDEXMBUGA1UEAxMOcGRpaHViLmhpLmlu  
Oi8vb3JjYXRpZC5oaS5pbmV0L29jc3AwJgYIKwYBBQUHMAGGGmh0dHA6Ly9vcmNh  
dGlkLnRpZC5lcy9vY3NwMFUGCCsGAQUFBzAChklodHRwOi8vaXNzdWVjYXRpZC5o  
aS5pbmV0L0NlcnRFbnJvbGwvaXNzdWVjYXRpZC5oaS5pbmV0X0lTU1VFQ0FUSUQo  
MykuY3J0MFIGCCsGAQUFBzAChkZodHRwOi8vb3JjYXRpZC5oaS5pbmV0L0NlcnRF  
bnJvbGwvaXNzdWVjYXRpZC5oaS5pbmV0X0lTU1VFQ0FUSUQoMykuY3J0MFEGCCsG  
AQUFBzAChkVodHRwOi8vb3JjYXRpZC50aWQuZXMvQ2VydEVucm9sbC9pc3N1ZWNh  
dGlkLmhpLmluZXRfSVNTVUVDQVRJRCgzKS5jcnQwIQYJKwYBBAGCNxQCBBQeEgBX  
AGUAYgBTAGUAcgB2AGUAcjANBgkqhkiG9w0BAQUFAAOCAQEALn2uGPE5cuOsDVWC  
NJLJbFFH/+JwVWJjD7+oLg6z29fB17FJUdh7RgcV8ObPItvbqg2B5v773WSXRNp3  
LQ3pRxefbwZdg2dbKTkcU9HSIX/WZHUUIFYGtXeQq7+9OJ5UY+Ta/Wg7ljKeLb3+  
7gzyjDhBsipu/oXRMXInU3CppIoR802shofl4rXCoOTQNz9suQYISkLJJd2UBxsn  
v1ytyPhqpdFr6zdsr2p/jFcxvj/uKYtMp9xeenHS8Nm/6y0sfPnzNpGTbxAhAoD0  
jPIqRzg+X5Wo/A2bcS0hRkLWuQAWSnIJRUT1v+Bm62iB/C/OLR3zFRuxy+NwqHH5  
q8+fMA==  
-----END CERTIFICATE-----

Si no tienes openssl o no quieres instalarlo siempre puedes usar Firefox para descargar el certificado. Navega a tu servidor, clica en el Candado que aparece en la barra de direcciones para ver la información sobre la conexión segura, clica en Más Información, clica _Ver Certificado, ve a Detalles y clica en exportar para guardar el fichero, renómbralo a *certificate.pem.

Confiando el certificado autofirmado

Copia o mueve el fichero a la carpeta que quieras (personalmente prefiero crear una carpeta ocula en ~/.git-certs/). Sólo queda decir a Git que confíe el certificado:

git config --global http."https://www.myserver.com/".sslCAInfo ~/.git-certs/certificate.pem  

Eso es todo, Git no comprobará si el certificado es válido para nuestro servidor nunca más 🙂