Migrando Hacia AndroidX

Cuando en el Google IO del 2018 se anuncia el famoso Jetpack de Android, definitivamente fue la apertura de un mundo de posibilidades y cosas nuevas para ver en Android. Android Jetpack es un "compendio" o conjunto de librerías que los chicos de Google agruparon con el objetivo de mejorar el desarrollo en Android.

Pero todo ovillo tiene su punto inicial y en el caso de Jetpack, es Android X. Android X es - por fín!, el siguiente paso a las support libraries, con las que venimos trabajando en la actualidad (y me refiero como actualidad a este 2019 donde "todavía" las support libraries siguen vigentes).

Cuando abrimos el archivo gradle del módulo de nuestro proyecto, casi siempre estamos acostumbrados a encontrarnos con esto:

Android Studio, Gradle Module

Y pasa el tiempo, las referencias no se actualizan y luego tenemos problemas de compatibilidad, porque si usamos la appcompat-v7:27.1.1 debemos mantener las versiones del resto de las librerías y entonces por ejemplo el Recyclerview "com.android.support:recyclerview-v7:27.1.1" debe seguir la misma línea y así sucesivamente. También hay definiciones que han quedado obsoletas como el "-v7" que posee la appcompat que originalmente indicaba la mínima versión de SDK necesaria y esto está completamente desactualizado, generado confusiones en los desarrolladores.

AndroidX que es el nombre resumido de "Android Extension Libraries", vienen a resolver estos problemas simplificando varias cosas!

En primer lugar, las existentes Support Libraries se encuentran mapeadas dentro de Androidx, con lo cuál, nada se pierde, todo se transforma. Para quienes quieran ir al detalle del mapeo entre librerías, les dejo el siguiente link con la tabla de mapeo:

https://developer.android.com/jetpack/androidx/migrate

A diferencia de las Support Libraries, AndroidX se mantienen y actualizan por separado con lo cuál si bien ahora en el inicio quizás veamos el mismo número de versión, luego según cada widget vaya tomando mejoras, los números de versión serán diferentes entre sí, sin generar ningún tipo de problema.

Entonces, si crearon un proyecto en los últimos meses usando Android Studio 3.2.1 o superior, donde el target version es API 28 y la versión del plugin de Gradle es 3.2.0 o superior, no tendrán problema en ejecutar el proceso de migración a AndroidX, tan simple como:

Botón derecho sobre el archivo gradle.
Refactor -> Migrate to Android X.

Aparecerá un popup como el siguiente invitándolos a a hacer un backup, dependiendo de la importancia del proyecto quizás es recomendable hacerlo, sino, pueden omitir este paso y ejecutar el proceso.

AndroidX proceso de migración ~ popup de confirmación

Una vez ejecutado el proceso, el cambio se visuliza de la siguiente manera:

ANTES:

build.gradle (Module:app) ~ Antes del Cambio a AndroidX

DESPUES:

build.gradle (Module:app) ~ Después del Cambio a AndroidX

Como parte de esta migración, hay algunos agregados, si por ejemplo le damos una mirada al archivo gradle.properties:

gradle.properties

Vemos que useAndroidX se encuentra en true y también enableJetifier que se encarga de traducir librerías de terceros que quizás usemos en nuestro proyecto y que no estén actualizadas a AndroidX para que todo siga funcionando sin problemas.

Notarán que ahora en el código de cada clase, las referencias de widgets son a AndroidX:

MainActivity.kt

Si la versión del plugin de Gradle no es 3.2.0 o superior y/o el target version del proyecto no es 28, les aparecerá un mensaje de error y deberán modificar estos valores, como por ejemplo lo debo hacer aquí, en el archivo build.gradle del proyecto, para llevarlo a la última versión del plugin de gradle:

build.gradle (del proyecto) ~ upgrade del build tools

Es probable que luego de hacer este cambio no solo se recompile el proyecto sino que les de la opción de hacer un "fix" completo del proyecto para compatibilizar por completo todas las versiones, si bien suena complejo, es solo darle clic al link que nos proporciona en el logcat.

Desde la última versión de Android Studio 3.3, cuando se crea un proyecto ya se puede elegir la opción de ir por AndroidX:

Android Studio 3.3.1 ~ Creando un proyecto

Tal y como Google viene empujando los cambios y novedades en los últimos años, todo indicaría que en una no muy lejana versión de Android Studio, ya los proyectos se crearían bajo esta nueva versión de librerías, dejando atrás el modelo actual.

Referencia Android Developer: https://developer.android.com/jetpack/androidx

Android Studio 3 (Beta 6): 6 novedades para destacar

Android Studio 3 "Beta 6" se encuentra disponible y siendo que parece haber varias novedades decidí armar un artículo con al menos algunas de las características que creo conveniente resaltar de lo que se viene. La estética en general cambió .

Creación de Proyectos

Por empezar, al crear un nuevo proyecto tenemos algo que nos habían prometido..., la posibilidad de incorporar Android Things algo no menor para quienes estamos trabajando o investigando sobre el tema.

Kotlin

Como no podía ser de otra forma lo primero a destacar es que Kotlin ya se encuentra incluido en Android Studio 3 y con esto me refiero es que, al igual que en su momento agregaron un checkbox con "support C++" ahora agregaron uno con "support Kotlin"..., una vez seleccionado, todo el proyecto ya queda en Kotlin.

No más"findViewById" (Kotlin Only)

Así es, para quienes reniegan de tener que hacer el tedioso findViewById y quizás también de tener que incluir librerías como Butterknfife para poder evitarlo, Android Studio 3 ya permite esto lamentablemente solo de la mano de Kotlin. Es decir, si tu proyecto ya lo realizas en Kotlin, acceder al valor de un EditText del layout es tan simple como colocar del lado del código el nombre del componente y listo ejemplo, editText.text = "Hola Mundo".

Peeerooo...., momento! Noten que (TextView) está remarcado... y cuando pongo el puntero del mouse por encima aparece la lamparita amarilla que me dice que "el casteo es redundante", en efecto...., ya no es necesario hacer el cast del findViewById, directamente el mismo retorna el tipo de objeto del elemento:

Opciones en el ConstraintLayout

Cuando hacemos clic derecho sobre un componente dentro de un layout con ConstraintLayout actualmente aparecen una enorme cantidad de opciones de alineación y otras utilidades. Ahora siguen las mismas, pero al menos las agruparon por algún tipo de criterio basado en si con utilidades de alineación de componentes, guías o posicionamiento. Lo mismo para en la barra de arriba cuando estoy en la vista de diseño. Es útil ya que ahora el desplegable es más corto y más simple de visualizar.

Errores y Warnings del Layout mucho mas amigables

Los errores o warnings del layout que solíamos tener como un icono arriba a la derecha y muy poco accesible, ahora si bien se siguen mostrando ahí para los problemas mas generales, lo particular se muestra en el Component Tree. Nice!

Merged Manifest

Algo un poco "bizarro" pero quizás útil, es que al abrir el xml del AndroidManifest, ahora tenemos una segunda solapa que dice "Merged Manifest". Lo que hace es justamente hacer una vista conjunta (o merge) entre los datos de configuración que tenemos en el manifest y los del gradle volviendo a tener al mejor estilo "Manifest del Eclipse" una visión global de los parámetros de configuración de la aplicación sin tener que estar viendo 2 archivos. Podemos ver en un solo lado tanto las actividades declaradas, los permisos, como la versión del código, el compile versión, min-sdk, target-sdk, etc. Pero...., no se puede editar, es solo una vista.

Profiler

El profiler ahora tiene un ícono arriba en la barra junto con los accesos que usamos diariamente:

Al hacerle clic, se abre el Android Profiler que parece haber tenido algunas mejoras, pero son más que nadas visuales:

Veremos cuánto tiempo más sigue en Beta y si habrá alguna novedad más. Para quienes desean ser un "Early Adopter" y probar todo lo nuevo, les dejo el link aquí:

https://developer.android.com/studio/preview/index.html

Android: Comenzando con Koltin - Clases, Variables y el Safety Null

En mi artículo anterior (http://paveliz.blogspot.com.ar/2017/05/android-comenzando-con-kotlin.html) les dejaba no solo los primeros pasos para configurar Android Studio y poder comenzar a trabajar en Kotlin, sino también un ejemplo práctico (https://github.com/paveliz?tab=repositories), con el cual ya pudiesen ver y comparar lo que usualmente escribían en Java y cómo es que se escribe ahora en Kotlin.

Mi pendiente a comenzar a resolver en los siguientes artículos es comenzar a dejarles una base teórica con explicaciones puntuales del lenguaje y por supuesto, continuar dejando código útil en Github.

Entonces, comencemos a ver algunos temas propios del lenguaje:

Clases

En Java escribir una clase cuya función no es más quizás que describir un dato no es complejo, pero hay algunos elementos que debemos respetar, getter, setter, constructor, etc:

public class Alumno {

private Integer documento;

private String nombre;

private String apellido;

public Integer getDocumento() {

     return documento;

}

public void setDocumento(Integer documento) {

     this.documento = documento;

}

...

}

En Kotlin esto se resuelve de la siguiente forma:

open class Alumno constructor (

  var documento: Int,

  var nombre: String,

  var apellido: String

) {

  init {

  }

}

- Si el constructor principal no tiene ninguna annotation o modificador, la palabra "constructor" puede obviarse.

- El constructor principal puede no tener ningún código en particular, pero si se desea implementar una inicialización, se puede hacer en un bloque "init".

- Se genera automáticamente todas las propiedades, así como algunos métodos útiles como toString (), equals() y hashCode().

val nuevoAlumno = Alumno (1212, "Pepe Nombre", "Pepe Apellido")

Toast.makeText(this, "Propiedad Nombre: " + nuevoAlumno.nombre, Toast.LENGTH_LONG).show()

- Por default, todas las clases en Kotlin son como Java "final classes". El "open" delante de la clase justamente es lo opuesto al final y permite que pueda ser heredada.

- Obviamente si el constructor tiene argumentos, deberemos completarlos a la hora de aplicar la herencia.

class Pablo () : Alumno(1212, "Pablo", "Veliz")

Lo que teníamos como "métodos" en Java para darle cierta funcionalidad a nuestras clases, en Kotlin se llaman Functions (Funciones) y se precede por la palabra reservada "fun":

fun onCreate(savedInstanceState: Bundle?) {

...

}

En Kotlin, una función siempre retorna un valor, si no lo especificamos retorna Unit que sería el equivalente a "void" en Java. Solo que en Kotlin, Unit es un objeto. Si especificamos un valor de retorno quedaría:

fun calcularSuma ( a: Int, b: Int) : Int {

     return a + b

}

Otra cosa interesante que podemos hacer en Koltin es definir valor default para los argumentos:

fun calcularSuma ( a: Int, b: Int = 0 ) : Int {

     return a + b

}

Noten que entonces ahora, yo podría simplificar el tema y enviar solo el primer argumento a "calcularSuma", el segundo me lo toma por default como cero.

calcularSuma(2, 5)

calcularSuma(2)

var vs val

Como comenté en mi post anterior, Kotlin tiene de una forma más natural implementado los conceptos de "inmutabilidad" de las variables. ¿qué significa esto?, básicamente el concepto habla de que el valor de una variable NO pueda ser modificado luego de su inicialización. En Java, todas las variables/objetos mutan (a menos que estén indicadas explícitamente como "final"). Mutar significa básicamente, que cualquier otra parte del código podría modificar su valor.

En Kotlin usaremos "val" usualmente para justamente crear variables inmutables. De hecho, el propio Android Studio al ver que definimos una variable cuyo valor es luego modificado o caso contrario, nunca se modifica, hará automáticamente la sugerencia de cambiar un var a un val o viceversa.

Otro tema muy interesante en Kotlin es que NO necesito declarar los tipos, los mismos se infieren de su contenido.

// Variables Inmutables SIN Declaración de Tipo:

val pepe = "Algo"

val numero = 22

// Variables Inmutables CON Declaración de Tipo:

val otroPepe : String = "Algo"

val otroNumero : Int = 22

// Variables mutables

var pais = "Argentina"

var otroPais : String = "Argentina"

El famoso tema del Safety Null

Uno de los temas que más se comenta de Kotlin es que es "seguro" en el sentido de que no tiene previene los famosos "Null Pointer Exception" de Java. Es cierto..., aunque en realidad no es tan así. Para ejemplificar esto, lo voy a comentar aquí y dejé un ejemplo en Github ().

Cualquier operación que hagamos en Java con un elemento que puede llegar a tener un valor nulo, dará como resultado en Null Pointer Exception. Y esto es algo que, si bien podemos intentar predecir cuándo escribimos el código nos puede pasar igual y Android Studio o cualquier otro IDE de programación jamás nos dará advertencia alguna. Ejemplo:

public String nombre = null;

if (nombre.length > 0) {

...

}

PUM!!!

Definitivamente esto dará como resultado una excepción. Quizás no fue nuestra intención que nuestra variable "nombre" quedara en null, quizás fue producto de un "getStringExtra" que vino vacío justamente por haber olvidado validar un campo en el layout..., miles de razones pueden llevar a este conocido error.

Pero cuando desarrollamos en Kotlin, pasa lo siguiente:

var parametro: String? = null

La variable "parametro" se debe inicializar y si no sabemos si puede ser null o no, agregamos al final del tipo de dato el símbolo del signo de interrogación "?". Lo que le dice esto a Kotlin es: "bueno..., esta variable de tipo String podría tener un valor o podría ser null ¿quien sabe?".

Si luego quiero realizar una operación como con Java usando el lenght, tendremos el siguiente problema:

Automáticamente el mismo Android Studio nos dirá que hay un problema, ya que de entrada habíamos avisado que la variable podía contener nulos, no podemos entonces operar con la misma directamente. Algo que podríamos hacer sería esto:

var i: Int? = parametro?.length

¿que es esto? es una "safety operation" u operación "segura" como Kotlin lo llama. Básicamente, en ambos lados declaramos con el "?" que la operación puede dar null y esto NO dará Null Pointer Exception.

Si estamos completamente seguros que la variable es segura y no dará problema de nulos, Kotlin nos deja declararlo de la siguiente manera:

var i: Int = parametro!!.length

Noten que ahora, en lugar de usar el signo "?" usamos dos signos de explamación "!!". Con esto, lo que le estamos diciendo a Kotlin es: "Tranquilo, esta variable no tendrá NUNCA nulos y la operación es segura". Claro está, que si bien esto deja tranquilo y libre de warnings y errores a nuestro Android Studio..., si llegamos a fallar y la variable llega a tener un valor nulo...PUM! . En este caso tendremos un "Kotlin Null Pointer Exception"..., con lo cuál se darán cuenta

Una de las tantas formas correctas en las que deje implementado esto en el ejemplo en Github (https://github.com/paveliz/ClassesVarsValsyNullsEnKotlin), es la siguiente:

if( ! parametro.isNullOrEmpty() ) {

Java tiene un .isEmpty() pero si lo usan, la operación continuará dando NullPointerException. Pero Kotlin tiene un isNullOrEmpty() que realmente nos soluciona el tema de poder operar con nuestra variable siempre y cuando tenga algo y no sea nula.

En mi próximo post, continuaré con la introducción a nuevos elementos de este lenguaje.

Android: Comenzando con Kotlin

Si eres desarrollador Android sabrás que Google confirmó al lenguaje Kotlin como oficial para comenzar a desarrollar en Android.

¿significa que dejaremos de desarrollar en Java?..., en principio diría que no, porque Android Studio no reemplazará un lenguaje por otro sino que, Kotlin se incorpora como una opción, pero debo reconocer que estos cambios comenzarán a marcar una tendencia y eventualmente los desarrolladores comenzarán en forma "natural" a migrar o directamente a desarrollar en Kotlin y llegará el día en que nadie recuerde que Android se programaba en Java anteriormente, estoy seguro de esto y es hacia donde Google desea ir.

Pero al menos en este artículo no pienso bajar a detalle temas del lenguaje, lo voy a dejar para otro post, pero sí voy a atacar el ¿cómo comenzar con Kotlin? y dar un primer ejemplo práctico.

Mi recomendación, es que de todas formas comiencen a leer sobre el leguaje para comprender desde la base su estructura, la forma en la que fue pensado, qué elementos nuevos posee y esto les ayudará a poder pasar en forma más intuitiva de Java a Kotlin. Recuerden que Kotlin no es muy diferente a Java y funciona con la misma JVM..., pero nuevamente, dejaré esto para otro post.

Entonces, manos a la obra..., en primer lugar, no es necesario descargarse si o si la versión beta del Android Studio 3 para comenzar a trabajar en Kotlin, si bien fue una de las primeras cosas que hice por curiosidad de ver lo que se venía, pueden instalar el plugin de Kotlin y trabajar con la versión actual de Android Studio (que al día de este post es la 2.3.2).

Pueden seguir para esto los pasos de la siguiente guía:

https://www.slideshare.net/paveliz/androidkotlin-primeros-pasos

Que está basada en la guía del sitio de Kotling:

https://kotlinlang.org/docs/tutorials/kotlin-android.html

Cabe aclarar que cuando fui a buscar el plugin de Kotlin me encontré con 3 elementos..., el que deben instalar es el remarcado:

Una vez agregado, no se emocionen..., todavía no van a poder ver nada nuevo. Debe crear un nuevo proyecto o abrir alguno existente y al estar arriba cualquier Activity, si van al menú de Code en la barra superior verán una nueva opción que dice: Convertir a Kotlin:

Básicamente lo que hará esto es convertir el código de la Activity que por default está en Java:

..., en Kotlin:

Como un primer paso, les dejo un ejemplo que he subido a Github (https://github.com/paveliz/EjemploKotlin1). Tengo una Activity muy simple donde en el Layout puse un TextView, un EditText y un Button. Les quedará algo así:

En la Activity, como de costumbre, cree el método del botón:

class MainActivity : AppCompatActivity() {

    override fun onCreate(savedInstanceState: Bundle?) {

        super.onCreate(savedInstanceState)

        setContentView(R.layout.activity_main)

    }

    fun clicBotonCambiar ( v : View) {

        val edtField = findViewById(R.id.editText) as EditText

        val txtField = findViewById(R.id.textView) as TextView

        txtField.text = edtField.text

    }

}

Noten que:

clicBotonCambiar

clicBotonCambiar no es un método, es lo que en Kotlin se llama un "Extension Function", que permiten agregar comportamientos a nuestra clase. Hay mucho para aclarar sobre esto, pero por ahora solo les digo que la ventaja del Extension Function es que puede "extender" una clase si necesidad de tener que pasar el objeto de la misma como argumento. El Extension Function actúa como si perteneciera a la clase.

Noten que en la definición de los argumentos, primero se coloca la variable, dos puntos y el tipo de dato de la misma (exactamente al revés de Java).

findViewById

Declarar un elemento del layout es muy simple, puede ser un "val" donde luego del findViewById hago el cast como "as [Object]".

Con "val" estoy definiendo un tipo de variable inmutable. La inmutabilidad es un nuevo concepto que viene con Kotlin. Un objeto inmutable es un objeto cuyo estado no puede cambiarse después de la instanciación.  Si necesita una versión modificada del objeto, debe crearse un nuevo objeto.

Los objetos "mutables" (como lo son por default en Java), se definen como "var".

txtField.text = edtField.text

Kotlin no tiene getters ni setters, por ende, todo lo que conocíamos como getText, getExtra, etc..., no está más y ahora se acceden como propiedades.

Procuraré lanzar un nuevo post con los detalles teóricos respecto de estos y otros grandes puntos del lenguaje Kotlin, pero al menos en este post me reservo esto, sin aturdirlos con la base teórica. El resultado es el mismo de siempre y dado que el ejemplo es muy simple no hay mucho truco, pero el tema es poder tener un primer acercamiento al código de Kotlin y pasar los temas que ya conocemos y son muy obvios para quienes venimos trabajando en Android con Java desde tiempo, a este nuevo lenguaje.

En breve, estaré subiendo más post relacionados a este tema ahondando más en el lenguaje, tema que - como comenté a principio de todo, les recomiendo comenzar a revisar tranquilos.

Github: https://github.com/paveliz/EjemploKotlin1

SlideShare: https://www.slideshare.net/paveliz/androidkotlin-primeros-pasos