lunes, septiembre 25, 2017

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í:


lunes, agosto 21, 2017

Android con Kotlin: Usando Lambda Expressions

Las expresiones lambda (o lambda expressions) que veremos en Kotlin, no son en realidad una completa novedad..., en Java se pueden usar y es algo que otros lenguajes como C# ya lo tienen desde aproximadamente el año 2006 (con .Net 3.0).

Pero, ¿que son las expresiones lambda?

Las expresiones lambda permiten pasar funcionalidad como argumento de una forma muy simple y sin tener que usar clases anónimas. Esto hace que simplifique mucho la codificación.

Supongamos que tenemos la siguiente función:

fun compare(a: String, b: String): Boolean = a.length < b.length

Mediante una expresión lambda se podría hacer los siguiente:

max(strings, { a, b -> a.length < b.length })

"max" es una función que toma el valor del segundo argumento, donde este segundo argumento es en sí, una función.

El formal en general de una expresión lambda es:

{
  param1, param2 -> //parámetros separados por coma
  param1 + param2 //código a ejecutar
}

Para terminar de ver esto con un ejemplo bien práctico, primero tomemos como referencia la implementación de un "OnItemClicListener" en un ListView en Java, tradicionalmente se vería de la siguiente manera:

mListView.setOnItemClickListener(new OnItemClickListener() {
  @Override
  public void onItemClick(AdapterView<?> parent, View view,
  int position, long id) {

  Log.d("onItemClick", "Se hizo clic") // Acá va la acción a realizar.

  }
});

Con un lambda expression en Kotlin, se simplificaría de esta manera:

mListView.onItemClickListener = AdapterView.OnItemClickListener { parent, view, position, id ->

    Log.d("onItemClick", "Se hizo clic") // Acá va la acción a realizar.

}

Como se puede apreciar, la diferencia en simplicidad y reducción de código es sumamente apreciable. No obstante, supongamos que view y id sean parámetros los cuáles no se les dará uso, la expresión podrían simplificarse aún más reemplazando esas argumentos que no estarán en uso por un "underscore":

mListView.onItemClickListener = AdapterView.OnItemClickListener { parent, _, position, _ ->

    Log.d("onItemClick", "Se hizo clic") // Acá va la acción a realizar.

}

Aún mejor, supongamos el siguiente clásico ejemplo del OnClickListener de un botón en Java:

button.setOnClickListener(new OnClickListener(){

@Override
public void onClick(View v){

doSomething();

}
});

En Kotlin, se reduce a una sola línea:

button.setOnClickListener({ view -> doSomething() })

Si los parámetros no son usados, directamente en lugar de reemplazarlos por un underscore, puede quitarlos, quedando:

button.setOnClickListener({ doSomething() })

Finalmente, como la función parámetro es única y el lambda también, puedo quitar los paréntesis quedando:

button .setOnClickListener { doSomething() }

Algo para destacar es que el mismo Android Studio nos va guiando y, si encuentra que podemos reemplazar el código que escribimos por una expresión lambda, nos lo siguiente actualizarlo en forma automática de la mano de la "lamparita amarilla" que usualmente aparece sobre el margen izquierdo de nuestro código.

Android Studio Kotlin Lambda Expression

Se puede ver un ejemplo completo e implementado de esto y otros temas más, en la siguiente aplicación que dejé completa en Github:


lunes, junio 05, 2017

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.



domingo, mayo 28, 2017

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.


lunes, mayo 08, 2017

Para Google los colores son Importantes en Android

Dentro de lo que es el sitio de guía y especificaciones para Material Design (https://material.io/), Google introduce un set de herramientas muy útiles a la hora de evaluar tamaños de pantalla, animaciones, elementos que cambian de tamaño en pantalla y ahora colores. La herramienta COLOR TOOL (https://material.io/color/), permite seleccionar e indicar los colores para los elementos principales de tu aplicación y la misma herramienta luego aplica todas las tonalidades compatibles con cada elemento en pantalla, según su jerarquía y acorde justamente a lo que Material Design especifica.

Solo a modo de "repaso", Google introduce Material Design en el año 2014 con el objetivo de establecer un estándar de trabajo a la hora de diseñar las pantallas de una aplicación móvil (https://developer.android.com/design/material/index.html). Material Design no se limita a colores y fuentes..., establece parámetros animaciones, interacciones con el usuario e inclusive promueve el uso de una serie de componentes creados para tener una mejor interacción y visualización en aplicaciones Android (Themes, Toolbar, CardView, RecycleView, Shadows, tipos de Drawables nuevos, etc). Uno de los objetivos más importantes que se persigue es el desarrollo de una experiencia "unificada" a lo largo de la diferente variedad de dispositivos que existen.

COLOR TOOL es realmente una herramienta muy bien lograda y simple de usar. Con solo seleccionar un color de la paleta (o indicar uno propio por código), la herramienta presenta cómo queda aplicado ese color y diferentes tonalidades del mismo según la jerarquía de elementos en cada componente de Android. 



Se puede seleccionar cada color Primary, Sencodary, Text P y S y la herramienta mostrará como quedan combinados a lo largo de 6 tipos distintos de pantallas que contienen diferentes componentes de Android.





En la sección de "accesibilidad", la herramienta presenta textos en diferentes tamaños y contrastes de colores para dejar en claro qué elementos quedarán visibles y apreciables por el usuario en forma correcta y cuáles no. Esto nos permitirá corregir el color selecionado en el paso anterior.



domingo, febrero 12, 2017

Stetho: Debugging en Android igual que en Web

Recientemente tuve la oportunidad de participar en una charla brindada por el equipo de trabajo de Android en Facebook acerca de cómo trabajan, procesos y tecnologías que usan en la construcción de una de las aplicaciones más usadas y descargadas a nivel mundial.

Pero este artículo no es sobre esto, sino sobre un tema que fue arrojado al público presente como un "tip" de trabajo y me sorprendió ver que realmente muy pocos conocían. Y es el uso de Stetho.

Stetho surge justamente como una de los tantos proyectos del equipo de desarrollo de Facebook con la intención de mejorar su forma de trabajo, concretamente, de debugging de aplicaciones Android. Así es como también hay otros proyectos que han surgido por parte de ellos como React, redex, Fresco, makeitopen, etc (https://code.facebook.com/projects/).

Cuando te encuentras trabajando en un proyecto Android ¿quién no se ha encontrado con el problema de realizar un buen proceso de debug de servicios rest y poder analizar los elementos que la app transfiere por HTTP ¿quién no se ha encontrado con el problema de poder acceder a los datos de SQLite?...y no tener que hacer cosas como acceder a los archivos, descargarse la base al escritorio y abrirla con un motor de SQLite local para poder ver lo que la app pudo guardar o no.

Para hacer una analogía práctica Stetho nos da el mismo el mismo beneficio que el "inspect" que usamos en Chrome cuando desarrollamos web..., de hecho, la solución se basa en el mismo concepto. Aquí en el screenshot se puede visualizar un ejemplo de esto que hablo. Todos los elementos de la app, bajo la misma consola de desarrollo que tiene Google Chrome.

Stheto Inspect
Stetho Inspect


¿cómo se usa esto?

Primero debemos agregar Stetho al Gradle:
compile 'com.facebook.stetho:stetho:1.4.2'
Sugiero también agregar:
compile 'com.facebook.stetho:stetho-js-rhino:1.4.2'
Nota: Esta es una de las opciones que Stetho tiene y es la más general. Luego tiene otras inclusiones particulares relacionadas al debuggin de HTTP. Para más detalles de esto ver los ejemplos y código en el sitio.

Luego, inicializamos el comoponente con esta línea:


public class MyApplication extends Application {
  public void onCreate() {
    super.onCreate();
    Stetho.initializeWithDefaults(this);
  }
}

Y listo!

Para probar su funcionamiento, debemos correr nuestro proyecto sea en un equipo o en un emulador y abrir Chrome. Una vez ahí, debemos colocar:

chrome://inspect/#devices

Ahí aparecerá nuestra aplicación y un link que dice "inspect", al hacer clic se abrirá otra pantalla con el conocido inspect de Chrome pero con todo el contenido de nuestra aplicación.

Chrome Inspect
Chrome Inspect


Entre las acciones más importantes y que en lo particular a mí me han sido de gran utilizar, puedo inspeccionar los recursos pudiendo acceder a los archivos de SharedPreferences y sobre todo a la base de datos de SQLite:

Stheto Inspect SharedPreferences SQLite
Stetho Inspect SharedPreferences, SQLite


No solo puedo ver la o las bases de datos que mi aplicación esté usando sino también las tablas y acceder a la edición del contenido mediante la escritura de consultas SQL. El otro punto que me ha sido de gran utilidad es el poder inspeccionar la interface de usuario igual que cuando hacemos debug de una página web. Stetho me muestra el árbol de componentes pudiendo acceder al detalle de cada uno:
Stheto Inspect UI
Stetho Inspect UI

Hay mucho más para investigar, pero Facebook lo tienen muy bien explicado en sus respectivas URL de referencia, espero lo usen y les sea tan útil como a mi.


http://facebook.github.io/stetho/

https://github.com/facebook/stetho