Forem: Armando Picón

[iOS] CocoaPods cheatsheet

Armando Picón — Fri, 06 Feb 2026 02:37:51 +0000

This post is just a reminder about how to use CocoaPods.

First things first...

What is CocoaPods

CocoaPods is a dependency manager for iOS projects.
It integrates third-party libraries into Xcode projects using a Podfile.

Install ruby

brew install ruby

Install CocoaPods

sudo gem install cocoapods

Verify the installation using

pod --version

Initialize CocoaPods in a project

First, go to the project folder (where .xcodeproj is located) and run

pod init

A minimal example of configuration

platform :ios, '15.0'

target 'YourAppTarget' do
  use_frameworks!

  pod 'Alamofire'
  pod 'SnapKit'
end

Key things:
• platform → minimum iOS version
• target → must match your app target name exactly
• use_frameworks! → required for many Swift pods

Install the dependency

pod install

This creates:
• Pods/ folder
• YourProject.xcworkspace

🚨 From now on, open the .xcworkspace, not the .xcodeproj.

Using a pod in code

import Alamofire

AF.request("https://example.com").response { response in
  print(response)
}

If it compiles → done.

Common commands

pod install     # install dependencies
pod update      # update dependencies
pod repo update # update specs repo
pod deintegrate # remove CocoaPods completely
pod search NAME # search pods

Typical problems & fixes

❌ “No such module”
• You opened .xcodeproj instead of .xcworkspace
• Target name mismatch in Podfile

❌ Build settings conflicts

pod deintegrate
pod install

❌ Slow installs

pod install --repo-update

Some additional notes

CocoaPods is mostly for legacy projects
For libraries that don't support SPM (Swift Package Manager)
Consider using only Swift Package Manager

Android - Scalable dependency management with version catalogs

Armando Picón — Wed, 13 Dec 2023 21:56:58 +0000

I’m revisiting some helpful content for starting a new Android project. One of the pain points is how to handle a ton of dependency declarations for multi-module projects. Here is where version catalogs come to our rescue.

Declaring dependencies

Before discussing the version catalogs, we will see how dependencies are being declared in an Android project. To declare a dependency in an Android project, you would add something like the following code in your build.gradle.kts file:

plugins {
  //...
}

android {
  //...
}

dependencies {
    // Here is where the dependencies are declared
    implementation("androidx.core:core-ktx:1.12.0")
    // ...other dependecies
}

Coordinates

One important concept to have in mind is the concept of coordinates. Each coordinate is composed by “[group]:[artifact name]:[version]”. For example, in the example above the coordinate of the core-ktx dependency is [androidx.core]:[core-ktx]:[1.12.0], so the same dependency can be decomposed in a declaration like this.

implementation(group = "androidx.core", name = "core-ktx", version = "1.12.0")

Keep in mind this concept; we will return to it later.

A common issue with multi-module projects

In case you have more than one module in your project, each dependency needs to be declared on every module that requires the specific dependency. The problem arises with this approach because of having repetitive declarations; every time you want to update a dependency version, you have to make the change in every gradle file where the dependency is declared. This makes dependency handling redundant and messy.

Here is where Version catalogs come to our rescue.

Version catalogs

Version catalogs is a feature of Gradle, so you can use it if you use Gradle as your build system in your Android project. This allows you to declare and organize all your dependencies in a single file, which acts as a catalog where each dependency is associated to a single alias, making this catalogs acts as a source of truth and it can be referenced in every gradle file.

To enable this option you need to follow these steps:

Create a new file into the gradle folder at the project level with the name libs.versions.toml.
Declare the dependencies into that file.
Reference these declarations in every gradle file of each module.

If you don't know where the gradle folder is, you can typically find it at the root project level; you can use the Project view to look at it.

At this point, you can ask… how these declarations must be made into that file?

Basic usage

Now, let's see the structure of the libs.versions.toml file.

[versions]
core-ktx = "1.12.0"

[libraries]
androidx-core-ktx = { group = "androidx.core", name = "core-ktx", version.ref = "core-ktx" }

In the most basic format you have to declare two sections [versions] and [libraries], the first one is used to declare versions for each dependency, the second is for the dependencies itself.

For this example, we took the same dependency that it has been declared in the first example of this article, in the gradle file. In order to make the core-ktx dependency available into the libs catalog, we associate the alias androidx-core-ktx to the GAV (group, artifact, version) coordinates.

The main benefit is these declarations are visible by all the modules in your project. So you can reference these declarations from your gradle file.

plugins {
  //...
}

android {
  //...
}

dependencies {
    // Here is where the dependencies are declared
    implementation(libs.androidx.core.ktx)
    // ...other dependecies
}

Note: Every time you added a new declaration in the TOML file you have to sync the project to make it available for the modules.

Also, using Version catalogs let you to reference the same version for multiple different libraries, for example:

[versions]
android-paging = "3.2.1"

[libraries]
android-paging-common = { module = "androidx.paging:paging-common-ktx", version.ref = "android-paging" }
android-paging-runtime = { module = "androidx.paging:paging-runtime-ktx", version.ref = "android-paging" }
android-paging-rxjava2 = { module = "androidx.paging:paging-rxjava2-ktx", version.ref = "android-paging" }

Here, we simplify the coordinates using the module to group the [group]:[artifact] pair and use the same version reference for all the android-paging dependencies.

Going a bit further

Not only you can declare the regular dependencies in that TOML file, you can declare your plugins and even create bundles for grouping dependencies.

How to declare plugins

To declare a plugin you only need to add the [plugins] section.

[versions]
//Here the versions are declared
android-gradle-plugin = "8.2.0"

[libraries]
//Here the libraries are declared

[plugins]
android-application = {id = "com.android.application", version.ref = "android-gradle-plugin"}

So, after syncing the project, we can change the references from this

// Top-level build file where you can add configuration options common to all sub-projects/modules.
plugins {
    id("com.android.application") version "8.2.0" apply false
    //... more plugins are placed here
}

To this

// Top-level build file where you can add configuration options common to all sub-projects/modules.
plugins {
    alias(libs.plugins.android.application) apply false
    //... more plugins are placed here
}

How to create your own bundle

To create a bundle, you have to add a [bundles] section into your TOML file. For example, here I’m adding the Room bundle.

[versions]
room = "2.6.1"
ksp = "1.9.0-1.0.13"

[libraries]
androidx-room-compiler = { group = "androidx.room", name = "room-compiler", version.ref = "room" }
androidx-room-ktx = { group = "androidx.room", name = "room-ktx", version.ref = "room" }
androidx-room-runtime = { group = "androidx.room", name = "room-runtime", version.ref = "room" }

[plugins]
kotlin-symbol-processing = { id = "com.google.devtools.ksp", version.ref = "ksp" }

[bundles]
android-room-bundle = ["androidx-room-ktx", "androidx-room-runtime"]

Again, you can use the bundle like this after syncing your project.

plugins {
    // More plugins are added here...
        alias(libs.plugins.kotlin.symbol.processing)
}

android {
  //...
}

dependencies {
    // Some dependencies are declared here
    implementation(libs.bundles.android.room.bundle)
    ksp(libs.androidx.room.compiler)
}

Conclusion

It’s also worth mentioning that using a version catalog is likely the best way to establish a single source of truth for all your project dependencies. It's also worth mentioning that the official documentation has a section about this topic.

You can experiment with different strategies using bundles to organize the necessary dependencies for each project, avoiding the tedious process of checking each Gradle file to see what you’ve declared.

References

Migrate to version catalogs

https://developer.android.com/build/migrate-to-catalogs

Sharing dependency version between projects

https://docs.gradle.org/current/userguide/platforms.html

Android - Desmitificando Clean Architecture

Armando Picón — Thu, 30 Dec 2021 17:22:28 +0000

Antes de comenzar…

Si es tu primera vez leyendo sobre Clean Architecture quizá te convenga saber algunas cosillas antes de seguir:

Clean Architecture es el título de un libro escrito por Robert C. Martin (aka. Uncle Bob)
No es una arquitectura en sí, sino una guía que encierra un conjunto de principios a seguir.
La base de esta guía se encuentra en aplicar los principios SOLID.
En términos generales, te intenta llevar a una estructura basada en el Dominio (Domain) como punto central de tu aplicación (la capa en la que se implementará la lógica de tu aplicación). ¿Alguien habló de Domain-driven development?
Un buen número de desarrolladores la confunde la arquitectura con N-capas.
No es el santo grial, es una expresión algo mainstream entre los desarrolladores y por ende sirve como una forma fácil de describirle a un desarrollador de qué manera se ha estructurado un proyecto.

¿Qué es una arquitectura?

Básicamente, es una estructura, una manera de distribuir los componentes que conforman una aplicación en distintas agrupaciones. Por esto mismo, no existe una única manera de organizar tu proyecto. Diversos aspectos como el estado de tu proyecto, el tamaño de tu equipo, el tiempo, etc influirán en las decisiones que tomes al momento de decidir la manera en la que organizarás los componentes de tu aplicación.

Clean Architecture en el mundo Android

Mucho se ha dicho y escrito sobre cómo aplicar Clean Architecture en las aplicaciones que desarrollamos, un buen número de desarrolladores te hablarán sobre Separation of concerns and testing como las principales características de seguir estos principios, suelen a su vez olvidar un aspecto muy importante sobre Clean Architecture y que consiste en que su base yace en la implementación de la capa de Dominio.

Dicho esto ¿cómo se estructuraría un proyecto base siguiendo estos principios? Para trabajar en esto es importante establecer dos consideraciones importantes:

Existe una regla en Clean Architecture por la cual toda capa exterior dependerá de una capa interior (y no al revés), quedando para el final la capa de Dominio sin dependencia alguna.

Existe un flujo de datos que pasa por todas las capas externas e internas tanto de ida desde que se efectúe el ingreso de datos por parte del usuario (o de los sensores), pasando por la lógica de negocio/aplicación y terminando en la persistencia de los datos o el envío de los mismos a un servicio remoto, como también de vuelta con el resultado de la operación con el servicio hasta la presentación del resultado a nuestro usuario.

Teniendo en cuenta estos dos aspectos, para una estructura básica contaríamos con tres módulos: presentation, domain y data. La relación entre estos sería de la siguiente manera:

¿Qué componentes irían en cada capa?

Es importante reiterar que al hablar de arquitectura, hablamos de organización y estructura, por lo tanto, la distribución y qué componentes en específico irán en cada módulo dependerá del patrón que decidas emplear y el propósito de cada módulo:

Domain deberá contener los elementos que contengan la lógica de tu aplicación y la lógica del negocio. Con ello en mente, tendremos clases de dominio, y además componentes que tendrán la lógica como son los Casos de Uso o Interactors. Este módulo NO debe depender del Android framework ni de dependencias de terceros. Este módulo puede ser un módulo Kotlin.
Presentation tendrá los elementos que permitan mostrar información a nuestro usuario, recibir datos del mismo o de sensores. Además de los componentes visuales propios de Android (Activity y Fragment) y su sistema de UI (archivos XML o funciones de Compose), si se siguen patrones como MVP o MVVM, tendremos también Presenters o ViewModels respectivamente. Este módulo es un módulo Android.
Data va a incluir todas las dependencias de networking (Retrofit, volley, etc) y de persistencia de datos (Room, SharedPreferences, DataStore, Firebase, etc). Si se emplea el patrón repositorio será en esta capa en la que tendremos la implementación de los repositorios y las fuentes de datos (data sources). Este módulo es un módulo Android también.

Seguramente aquí te podría surgir la siguiente duda: si Domain no tiene visibilidad de Data ¿cómo es que podríamos inyectar los repositorios en nuestros casos de uso? La respuesta se encuentra en el principio de Inversión de Dependencia (Dependency inversion) de SOLID.

Dependency inversion principle

Este principio de SOLID establece dos consignas:

Los módulos de alto nivel no deberían importar nada de un módulo de bajo nivel. Pero ambos deberían depender de abstracciones (interfaces).
Las abstracciones no deberían depender de los detalles. Los detalles (las implementaciones concretas) deberían depender de las abstracciones.

Teniendo en mente esto, nuestro módulo Domain deberá ser propietario de la interfaz del repositorio que se implementará dentro del módulo Data.

En código esto luciría más o menos de la siguiente manera, en el módulo Domain estaría la abstracción de un BookRepository.

interface BookRepository {
    suspend fun getBooks():List<Book>
}
class GetBooksUseCase(
    private val bookRepository: BookRepository
) { /*...*/ }

Mientras que en el módulo Data iría su implementación.

class BookRepositoryImpl (...) : BookRepository {
    override suspend fun getBooks(): List<Book> { /* ... */}
}

De este modo al momento de crear una instancia de nuestro caso de uso le podremos inyectar la implementación debido a la interfaz que hemos declarado.

Conclusiones

Podría mencionar algunas cosas como parte de la conclusión:

Contar con una arquitectura o forma de organizar los componentes es mejor que no tener ninguna.
Clean Architecture no es una arquitectura en sí, pero nos provee de una guía a seguir para estructurar nuestros proyectos.
Existen otras arquitecturas que no cuentan con mucha fama, pero no por ello son menos útiles.
Teniendo esta estructura, puedes usar lo que se te antoje tanto en la presentación (sea Views-XMLs o Compose) como a nivel del acceso a datos (Retrofit, Room, SharedPreferences, etc).
En mi experiencia, la buena aplicación de los principios SOLID te da una buena base para ir perfilando la arquitectura de tu proyecto.
La relanzada guía oficial de arquitectura de Android no sigue Clean Architecture, pero sí provee de una arquitectura separada en capas.

Referencias

Kotlin - Scope Functions (let, with, run, apply & also)

Armando Picón — Mon, 22 Feb 2021 00:36:49 +0000

Empecemos viendo este código:

  name?.let{
    //...
  }

Estoy seguro que en algún momento lo has visto y sabes que es una forma de validar que name no sea nulo antes de emplear el valor dentro del bloque de código dentro de la función let. Pero ¿realmente sabes las implicancias del uso de dicha función? Si la respuesta es no, pues esta publicación es para ti.

Definiendo las scope functions

Según la documentación oficial son funciones cuyo único propósito es "ejecutar un bloque de código dentro del contexto de un objeto". Creo que la explicación es algo sencilla, básicamente es una forma de organizar nuestro código y hacerlo mejor leíble.

¿Qué scope functions trae Kotlin?

Básicamente tenemos 5 scope functions: let, with, run, apply y also; adicionalmente hay 2 funciones extras takeIf y takeUnless que nos permitirán adicionar algunas validaciones de estado en medio de una cadena de invocación (o en tras palabras cuando concatenas varias scope functions) y que suelen emplearse junto con las 5 anteriores.

Como la documentación lo señala hay dos elementos que distinguen a una scope function de otra:

la forma en que se referencia al objeto de contexto
el valor de retorno

Por la forma en que se referencia al objeto de contexto

La razón por la que tenemos un it o un this es para simplificar o acortar el nombre de la variable original y, básicamente, te dirá si el objeto va a recibir la lambda (para el caso del this) o si el objeto va a pasarse como argumento de la lambda (para el caso de it).

Entonces, ¿en qué casos el objeto de contexto va a recibir la lambda? run, with y apply y ¿en qué casos el objeto de contexto se pasará como argumento? let y also.

Por el valor de retorno

Para esta situación tendremos el retorno del mismo objeto de contexto para el caso de apply y also o el valor de resultado de la lambda en el caso de let, run y with.

¿Qué función elegir?

Teniendo estas dos distinciones en mente, la documentación oficial detalla cada una de las funciones y los posibles escenarios de uso. De esa misma documentación saqué este cuadro que ayuda mucho a resumir lo dicho anteriormente:

Función	Referencia de objeto	Valor de retorno	¿Es una extension function?
`let`	`it`	Resultado de la lambda	Sí
`run`	`this`	Resultado de la lambda	Sí
`run`	-	Resultado de la lambda	No, cuando se llama sin el objeto de contexto
`with`	`this`	Resultado de la lambda	No, porque toma el objeto de contexto como argumento
`apply`	`this`	Objeto de contexto	Sí
`also`	`it`	Objeto de contexto	Sí

También la documentación brinda una pequeña guía de referencia:

Ejecución de una lambda en objetos non-null: let
Introducir una expresión como una variable en un ámbito local: let
Configuración de un objeto: apply
Configuración de un objeto y computación del resultado: run
Ejecutar sentencias donde una expresión es requerida: run a secas sin objeto de contexto ni como función extendida
Efectos adicionales: also
Agrupar llamadas a funciones en un objeto: with

takeIf y takeUnless

Estas dos funciones que vienen en la biblioteca estandar de Kotlin, no son consideradas scope functions; sin embargo, se emplean junto con ellas y sirven para realizar algunas validaciones.

La documentación oficial tiene algunos buenos ejemplos de cómo emplearlas.

Conclusión

Me resultan super interesantes las scope functions y este artículo tiene por intención hacer un breve resumen de en qué consisten y cuando emplearlas. Es importante practicar su uso para acostumbrarse a sus diferencias y casos de uso, dado que por lo similares que son resultado fácil confundirlas y equivocar su uso.

¿Qué nos dejó el 2020 y que nos traerá el 2021?

Armando Picón — Fri, 01 Jan 2021 03:36:42 +0000

Hola amigos y amigas de Codalot Podcast, que año para complicado el que nos tocó pasar, cierto? y quería empezar expresando mis condolencias a todos los que sufrieron de la pérdida de algún ser querido o de alguna persona cercana producto de esta pandemia.

Si bien es cierto que diversos sectores económicos sufrieron de un gran impacto producto de la crisis que se generó por causa de las medidas que tomó cada gobierno, producto de ello se perdieron muchos puestos de trabajo; sin embargo, dentro de las ocupaciones que no sufrieron tanto durante esta pandemia estuvieron los programadores y los desarrolladores de software.

Si fuiste uno de estos, puedes sentirte privilegiado y a su vez puedes sentirte feliz de haber tomado la decisión de dedicarte a esto.

El año del trabajo remoto

Este año que termina ha sido un año lleno de desafíos y de cambios significativos para cada uno de nosotros. Muy aparte de las cuarentenas y demás restricciones dictaminadas por cada gobierno, fue el año del trabajo remoto o home office.
Un problema latente con el trabajo remoto en este tiempo es que, sumado al hecho de que muchos de nosotros no podíamos salir, puede llegar a ser tedioso y muy agotador. Por eso se torna importante contar con rutinas, generar hábitos, aprender a desconectarse y aprender a ser creativos para no llegar al colapso.

Sin embargo, para los escépticos del trabajo remoto, ahora ya se tiene evidencia de que esta dinámica bien implementada puede ser no solo beneficiosa sino también altamente productiva. Lo que abriría las puertas para que se armen espacios de trabajo híbridos donde el que quiera pueda ir a una oficina a trabajar y el que no lo desee pueda trabajar desde donde le plazca. Evidentemente, esto dependerá de la forma en que vaya evolucionando la crisis.

El mundo Android en el 2020

En el mundo Android, este fue el año de las llamadas habilidades de Desarrollo Moderno en Android o conocido en inglés como “MAD skills”, se ha hecho mucho esfuerzo en la adopción de Kotlin por parte de Android en las diferentes dependencias o bibliotecas que se han venido trabajando. Esto ha permitido potenciar el conjunto de bibliotecas que yacen bajo el nombre de Jetpack y que forman parte de la manera en que Google recomienda la construcción de las nuevas aplicaciones, hecho que nos debe llevar a una necesaria actualización y adopción.

También, se ha hecho incapié en el uso de App Bundle, una nueva forma de distribución que permite la optimización de los recursos de nuestras aplicaciones.

Adicionalmente, han habido mejoras significativas en la construcción de las UIs mediante el uso de componentes como ConstraintLayout 2 y MotionLayout. Los cuales han de estar muy vigentes también durante el próximo año.

Finalmente, con las nuevas actualizaciones de Android como sistema operativo han llegado nuevas restricciones al acceso a data sensible que debemos tomar en consideración si deseamos mantener nuestras aplicaciones vigentes.

De hecho, tras el apoyo de Google hace 3 años, hoy en día no cabe duda del valor que Kotlin tiene para nosotros y, de hecho, si no estás familiarizado con dicho lenguaje tus opciones de empleabilidad van a caer dramáticamente.

Las comunidades se reinventaron

Las comunidades de desarrolladores también se vieron en la necesidad de adaptarse; tuvieron que pasar de organizar eventos de forma presencial con toda la logística que ello conlleva, a organizarlas de manera virtual. Pasaron de buscar espacios físicos a buscar plataformas de streaming que facilitaran la organización de pláticas.

Lo anterior también llevó a replantearse la necesidad de cobrar por el acceso a los eventos, dado que ya no se cuenta con el atractivo inherente de un evento físico, algunos eventos pasaron a cobrar algo simbólico o simplemente a liberar la entrada.

Esto también provocó el replanteamiento de las charlas brindadas por los speakers, dado que anteriormente tenía sentido compartir la misma presentación en múltiples lugares con público distinto en cada una y ahora una charla dada en un evento tranquilamente es accesible a través de las grabaciones que podían quedar en Youtube, lo que los lleva a presentar algo nuevo en cada presentación.

¿Qué vendrá en el 2021?

Este año que viene será el año de Compose, una nueva forma de construir interfaces de manera declarativa y que viene siendo escrita enteramente en Kotlin, y de Hilt, una dependencia que crea una capa de abstracción sobre Dagger, y que nos permitirá efectuar la inyección de dependencias de una forma más natural. Ambos, van a contar con sus primeros releases estables durante este próximo año.

No podemos dejar de lado la mención a Kotlin Multiplatform, una solución que permite compartir código durante el desarrollo de aplicaciones multiplataforma y que se ha venido cocinando durante un buen tiempo, ahora mismo se encuentra aún en alpha, pero podríamos ver sus primeros betas en el trascurso de este 2021 también.

Otro cambio más que se nos viene será la adopción de nuevos nombres código o codenames para las nuevas versiones de Android Studio empezando por la versión 4.3 que además de cambiar el esquema de versionamiento que estará más alineado con lo que se viene haciendo con IntelliJ Idea nos traerá un nuevo nombre código Android Studio Artic Fox.
https://android-developers.googleblog.com/2020/12/announcing-android-studio-arctic-fox.html

Este nuevo año traerá consigo muchas adaptaciones de lo viejo a lo nuevo; la entera adopción de Kotlin, la adopción de los MAD skills, etc.
https://developer.android.com/series/mad-skills

Claro está que más allá de las novedades, lo que no cambiará será la necesidad de conocer cosas tan fundamentales como los buenos principios de programación, la adopción de patrones de diseño de software, entre otros conocimientos que nos ayudarán a escribir y estructurar nuestro código de mejor forma, y que a su vez nos llevará a desarrollar mejores aplicaciones.

Cierre

Espero que este nuevo año traiga consigo cosas positivas, que puedan seguir cuidándose a ustedes y a sus familias. Y que podamos seguir creciendo en medio de la adversidad que hoy vivimos. Un abrazo a todos y les deseo un Feliz Año Nuevo 2021.

Adios!

Kotlin Coroutines 101 — Jobs

Armando Picón — Sun, 17 May 2020 18:33:01 +0000

Kotlin Coroutines 101 — Jobs

En este artículo estaré vamos a mencionar algunos aspectos que encuentro interesantes sobre los Jobs.

¿Qué es un Job?

En el primer artículo que escribí tuvimos ocasión de lanzar una corutina mediante la acción de un botón. Pero ¿qué pasa si por algún motivo queremos verificar el estado de la corutina o cancelarla, si fuera necesario?. Es aquí donde entra a tallar la tarea de un Job.

Un Job es una representación de una corutina y nos va a permitir realizar algunas acciones sobre ella.

¿Cuáles son sus estados?

Los Jobs cuentan con estados, los cuales listaré a continuación:

Ciclo de vida de un Job

New : representa el estado de creación de una corutina y la asociación de un Job a ella.
Active : este estado representa el momento en el que se inicia ejecución y mantiene la ejecución de una corutina.
Completing : este estado representa el momento en que la corutina ha finalizado su ejecución y precisa esperar a que otras corutinas asociadas a ella o en una relación de padre-hijo finalicen.
Completed : este estado representa el estado final de una corutina, el momento en el que toda su ejecución, incluyendo las corutinas hijas, ha finalizado.
Cancelling : este estado representa el momento en el que se ha cancelado la corutina y se espera la cancelación de los Jobs asociados a ella.
Cancelled : este es el estado final una vez que se ha procedido a la cancelación total o completa.

Debido a la existencia de estos estados, es posible mediante un Job acceder a las siguientes propiedades:

isActive : esta propiedad nos permitirá saber si un Job se encuentra en estado activo o no.
isCancelled : esta propiedad nos permitirá saber si un Job ha sido cancelado o no.
isCompleted : esta propiedad nos permitirá saber si un Job ha finalizado o ha completado todas sus operaciones.

¿Cuándo emplear estas propiedades? La respuesta sencilla sería emplearlas en momentos en los que la ejecución o lógica de tu corutina demande saber si debe continuar o no si el estado de la misma cambia.

La función invokeOnCompletion

Un aspecto interesante de los Jobs es que es posible ejecutar código una vez que estos finalizan y esto es gracias a la función invokeOnCompletion(), esta función recibe como parámetro un objeto nullable de tipo Throwable? que nos permitirá validar la causa por la que una corutina fue cancelada.

job1.invokeOnCompletion { throwable ->  
    log("Complete my job 1")
    throwable?.let {  
        log("There is a throwable object!")
        when ( it ) {
            is CancellationException -> {
                log( it.message ?: "Without message")
            }
        }
    }  
}

¿Cómo cancelar un job?

Cancelar un Job se puede conseguir mediante la invocación de su función cancel(). Sin embargo, te va a pedir que pases una instancia de la clase CancellationException, preferiblemente hay que agregarle un mensaje que indique la causa por la que se está cancelando el Job.

¿Cómo concatenar jobs?

Concatenar Jobs es relativamente sencillo, para ello requerimos ejecutar la función join(). El comportamiento por defecto de la función join() implica que la corutina que lo invoque se suspenda hasta que este Job esté completo. Sin embargo, si al builder de turno le pasamos el parámetro start=CoroutineStart.LAZY lo que acontecerá es que dicho Job pasará a un estado activo en el punto en el que join() sea invocado.

¿Cómo definir una relación de padre/hijo entre Jobs?

Definir una relación de padre e hijos es posible si pasas el Job como parte del contexto de la corutina que quieres definir como Job hijo.

val job1 = coroutineScope.launch(start = CoroutineStart.LAZY, 
                                 context = handlerException) {...}

val childCoroutineScope = CoroutineScope(Dispatchers.Main + job1)
val job2 = childCoroutineScope.launch{...}

¿Cómo manejar una excepción en un job?

Para manejar excepciones tienes dos forma; la primera, de forma tradicional usando un try/catch en la sección de código que quieres asegurar; la otra, es declarando una instancia de CoroutineExceptionHandler, el cual recibe como parámetros tanto un objeto conteniendo información sobre el contexto de la corutina y un objeto del tipo Throwable. Este objeto debe pasarse como parte del contexto de la corutina.

val handlerException = CoroutineExceptionHandler {
    coroutineContext, throwable ->  
        run {  
                log("$coroutineContext - ${throwable.message}")
        }  
}  

val job1 = coroutineScope.launch(context = handlerException ) {...}

Para complementar les dejo un video para complementar el contenido de este artículo, regálenme un Me gusta si les es de utilidad y un comentario en el video.

Kotlin Coroutines on Android 101

Armando Picón — Mon, 27 Apr 2020 06:25:32 +0000

Las corutinas son una de las características que gracias a Kotlin tenemos hoy en día y que busca simplificar la forma en la que se ejecutan tareas asíncronas. Este artículo tiene por objetivo hacer un repaso por los conceptos claves para entender cómo funciona.

Las corutinas actúan de forma similar; sin embargo, es importante recalcar que no son hilos.
Varias corutinas pueden ser ejecutadas en un mismo hilo.
Internamente se hace uso de un pool de hilos que nos proveerá el sistema.
Las funciones suspendidas o suspend functions es una variante de nuestras funciones regulares pero que pueden ser pausadas y resumidas en un momento posterior.
Para la ejecución de corutinas o funciones suspendidas es necesario establecer previamente el ámbito o scope en el que van a ser ejecutados (Ej. CoroutineScope)
Además del ámbito, la ejecución de una corutina necesita un punto de entrada que se establece mediante el uso de un coroutine builder (Ej. launch{} o async{}).
Para establecer en qué conjunto de hilo o hilos se ejecutarán nuestras corutinas y funciones suspendidas se dispone de los Dispatchers (Main, IO y Default).
Las funciones suspendidas solo pueden ejecutarse dentro de una corutina o desde otra función suspendida.

No te preocupes si por el momento todo lo que he señalado hasta aquí se lee como chino; vamos a ejemplificar estos puntos e irlos explicando poco a poco.

Agregar dependencias

Como primer paso para entrar al mundo de las corutinas debemos agregar las siguientes dependencias a nuestro proyecto. Toma en consideración que a la fecha de publicación de este artículo la versión existente es la 1.3.4, tal vez para cuando tú leas este artículo esta versión haya cambiado.

    def coroutines_version = "1.3.4"
    implementation "org.jetbrains.kotlinx:kotlinx-coroutines-core:$coroutines_version"
    implementation "org.jetbrains.kotlinx:kotlinx-coroutines-android:$coroutines_version"

Crear layout

Para centrarnos en probar las corutinas vamos a crear una interfaz sencilla que contenga un elemento de tipo Button con el id @+id/button_launch y un elemento TextView con el id @+id/text_result. ¿Cómo se deben distribuir en la pantalla? Es algo que dejaré a tu criterio.

Preparar nuestras funciones base

Antes de tocar las corutinas necesitaremos crear algunas funciones utilitarias como las que muestro a continuación. Las puedes agregar a tu implementación de tu clase MainActivity.kt (asumiendo que no le cambiaste el nombre por defecto al momento de crear tu Activity):

fun showResult (result: String){
    // Aquí vamos a aprovechar el uso de los synthetic imports para obtener
    // la referencia al textview que agregamos en nuestro UI directamente
    text_result.text = text_result.text.toString() + result + "\n"
}

fun log (message: String){
    // Emplearemos esta función para ayudarnos a identificar el hilo en el 
    // que se está ejecutando nuestra corutina. No siempre será el mismo hilo.
    println("[${Thread.currentThread().name}]: $message")
}

A continuación, dentro de nuestra función onCreate() vamos a agregar la invocación a la función setOnClickListener() de nuestro botón.

button_launch.setOnClickListener {
   // Dentro vamos a escribir nuestra primera corutina
}

Vamos con las corutinas

Vamos a escribir un ejemplo bastante común, vamos a simular la invocación a dos servicios que nos retornarán valores aleatorios.

Para conseguir esto primero escribiremos un par de funciones como te las presento a continuación, estas funciones van a escribir en los logs en qué hilo se está ejecutando, luego va a esperar un determinado tiempo en milisegundos y, finalmente, retornarán un resultado (estamos retornando valores String pero también podríamos retornar otro tipo de valor):

suspend fun getApiResult1 (): String {
    log("Get result from suspend function 1")
    delay(3000) // milisegundos
    return "result 1"
}

suspend fun getApiResult2 (): String {
    log("Get result from suspend function 2")
    delay(1500) // milisegundos
    return "result 2"
}

De estas dos funciones suspendidas es importante notar el uso de la función delay() la cual cumple un rol similar a Thread.sleep() pero sin bloquear el hilo y debido a que en sí misma es también una función suspendida, la regla nos indica que solo se pueden ejecutar desde una corutina o dentro de otra función suspendida (se lee redundante pero es así).

Ahora vamos a armar la implementación de la corutina con su correspondiente punto de entrada:

button_launch.setOnClickListener {
    // Dentro vamos a escribir nuestra primera corutina
    CoroutineScope(Dispatchers.Main).launch {
        executeRequest()
    }
}

Aquí también estamos haciendo uso de la función withContext() y mediante Dispatchers.Main le estamos indicando que la ejecución de esta corutina empezará en el hilo principal. Adicionalmente, hacemos uso de la función launch la cual marcará el inicio de la corutina.

Por razones ilustrativas vamos a agregar un par de funciones adicionales, primero esta:

suspend fun executeRequest() = withContext(Dispatchers.IO) {
    val result1 = getApiResult1()
    showResult(result1)
    val result2 = getApiResult2()
    showResult(result2)
}

Aquí también estamos haciendo uso de la función withContext() el cual especificará que el bloque de código que encierra se va a suspender en el grupo de hilos que determina el Dispatcher, en este caso Dispatchers.IO, el cual está optimizado para la realización de tareas de networking y escritura en disco.

Si intentamos ejecutar el código hasta aquí (espero que lo intentes), seguro la aplicación se va a romper ¿alguna idea del por qué? Dale una vuelta o checka la excepción que salió en tu consola.

Only the original thread that created a view hierarchy can touch its views.

Pero ¿qué pasó? bueno, resulta que gracias al withContext(Dispatchers.IO) esta última función se está ejecutando en los hilos de IO y no en el Main Thread o Hilo de UI. Vamos, entonces, a corregir este problema agregando una última función:

suspend fun sendResultToMainThread(result: String) = withContext(Dispatchers.Main){
    log("Display $result")
    showResult(result)
}

Si lo hiciste bien podrás apreciar lo siguiente en tu consola de Logcat:

[DefaultDispatcher-worker-1]: Get result from suspend function 1
[main]: Display result 1
[DefaultDispatcher-worker-1]: Get result from suspend function 2
[main]: Display result 2

Y listo, podemos apreciar los cambios que se van haciendo a medida que vamos ejecutando cada paso de nuestra pequeña aplicación. Ojo que no hemos empleado un adecuado diseño y hemos puesto todo dentro del Activity, pero la intención es ilustrar cómo funcionan los cambios de contexto durante la ejecución de la corutina y las funciones suspendidas.

Si les gustó este artículo, podría continuar profundizando en el tema y repasar otros conceptos.

Mi nuevo proyecto: Codalot Podcast

Armando Picón — Sun, 29 Mar 2020 04:38:33 +0000

Desarrollo móvil y tecnología en un solo podcast

Desde octubre del año pasado (2019) dejé de participar como co-host de Android Dev Podcast en español. Estoy agradecido por el tiempo porque me brindó muy buenas lecciones.

Tras mi salida del programa de podcast en el que participé durante un año, andaba dándole vueltas a diversas ideas para dedicar mi tiempo.

Hasta el momento debo decir que participar de un podcast me parece una experiencia genial. La posibilidad de entrevistar a otros desarrolladores o profesionales, plantearles preguntas para aprender y conocer más de lo que hacen, intercambiar ideas y, sobretodo, compartir todo este con la comunidad.

Iniciando la creación de un podcast desde cero

Con esto en mente decidí armar mi propio podcast y, como nos pasa con las variables, decidir qué nombre ponerle fue uno de los aspectos más difíciles de decidir. Porque no se trata solo de ponerle un nombre y ya, la elección del nombre va acompañada de preguntas como ¿será un podcast personal o de tecnología? y si será de tecnología ¿el nombre debe brindar la opción de abrir la temática a temas más allá del desarrollo móvil o no?, ¿el nombre debería estar en inglés o en español? ¿será lo suficientemente corto para pronunciar pero sea fácil de recordar también?

Al final de este proceso quedó Codalot y que sería un podcast que iniciaría hablando de desarrollo móvil (mi campo actual de trabajo), pero que eventualmente, en futuras temporadas pudiera tocar temas nuevos como desarrollo front, backend, machine learning, inteligencia artificial, periodismo de tecnología, etc.

¿Por qué Códalot? long-short story: antiguamente, era el nombre que recibió una iniciativa educativa que tuvimos con un buen amigo hace muchos años atrás y que, con el tiempo y las circunstancias de la vida, cayó en desuso. Tiempo atrás hablé con este amigo y me dejó a mi albedrío decidir qué hacer con el nombre. Debo confesar que no fue el nombre que había decidido ponerle al podcast, pero al final, después de indagar un poco, el nombre sonaba bien. Codalot se escucha como Lancelot, Camelot o Code-a-lot.

Ya tenemos un nombre y ¿dónde se va a alojar nuestro podcast?

Buscando alojamiento para nuestro podcast

Otro desafío en nuestro camino rumbo a convertirnos en P̵o̵k̵é̵m̵o̵n̵ ̵m̵a̵s̵t̵e̵r̵s̵ Podcasters es encontrar un buen alojamiento para nuestros episodios.

Aquí hay que considerar varias cosas. ¿Queremos tener el control sobre todo aspecto de nuestro podcast o que alguien más nos provea del servicio? Y si queremos que alguien nos provea del servicio ¿Buscamos un servicio gratuito o uno pago?

Si quisiera hacerlo todo desde cero habría que considerar armar una landing page para el podcast, reservar un repositorio para nuestros episodios (puede ser pago como Amazon S3 o gratuito como Archive.org), generar el RSS de nuestro programa y crear cuentas en cada servicio de distribución (Spotify for Podcasters, Podcast Connect by Apple, Google Play Podcast Portal, Pocketcast, etc).

Como no quería invertir mucho tiempo en todo ello, me fui por una plataforma que me proveyera de todo lo necesario para que solo me preocupe por grabar. De todos los servicios que vi me quedé con el servicio gratuito que brinda Anchor.fm.

¿Qué implica usar Anchor.fm?

Implica que solo puedes tener un podcast por cuenta, que agreguen su loguito en el arte visual de tu podcast, que tengas la posibilidad de monetizar (si vives en EUA), que puedas grabar segmentos a través de sus diferentes plataformas, pero el principal valor fue que te distribuye en una buena cantidad de servicios automáticamente (incluyendo Spotify, excluyendo Apple Podcast).

Es importante mencionar que si deseas acceder a los stats de Spotify, puedas reclamar tu podcast empleando el correo que asignaste a tu podcast. No es un proceso difícil, pero es importante tenerlo en cuenta.

Si eventualmente el programa crece y quisiera llevarlo a un plano más profesional, tal vez requiera de otro tipo de servicios; como todavía es prematuro no he revisado que tan complicado podría ser abandonar la plataforma.

¿Y qué onda con el hardware?

Para empezar un podcast diría que lo más importante es el contenido y que así juntito está la calidad del audio. Como muchas cosas, soy de la idea que lo primero es empezar y ver si le agarramos el gusto. Cuando participaba del anterior programa lo hacía con el micrófono de la laptop, luego de agarrarle el gusto invertí un poco de dinero para comprar un micrófono.

El micrófono que adquirí fue un Yeti by Blue. Ya conocía este micrófono porque lo había empleado años atrás cuando me tocó grabar un curso para una plataforma online y conocía de sus opciones. Además de proveer una buena calidad de sonido, los modos que trae consigo te permiten usarlo también para entrevistas presenciales con más de una persona. Les recomiendo revisarlo.

¿Y el software?

Para grabar cada episodio me valgo de la plataforma Zencastr, en su plan gratuito te permite contar con 3 participantes por grabación, te brinda almacenamiento local e integración con Dropbox, lo cual permite que al final de cada sesión tengas el audio por separado de cada participante en la nube, esto es suficiente para luego pasar a la post-producción.

Para juntar los audios, editarlos y generar el archivo de audio que subiré a Anchor empleo Audacity, una aplicación gratuita muy conocida que permite realizar ediciones de audio. Esto es suficiente para preparar el audio final.

Planeación de cada episodio

El contenido es un aspecto importante del podcast. Para ello lo que hice fue planear de antemano sobre qué temas quería hablar en una primera temporada.

Recibí el buen consejo de planificar de 6 en 6 los episodios. Partiendo por enumerar un título genérico de la temática de cada episodio y, luego, por cada uno, coordinar la participación del invitado, enumerar las preguntas o dudas que puedan surgir de uno mismo o de la comunidad, armar un pequeño delineación de la estructura del episodio (incluyendo la apertura, la presentación y el cierre).

También, es bueno practicar un poco las transiciones, familiarizarse con el contenido del tema a tratar, todo esto con el fin de hacer que la dinámica de cada episodio sea fluída. Igual, es algo que se va mejorando con el tiempo y a medida de que se vaya ganando experiencia.

Sin duda alguna entrar al mundo del podcasting es genial, espero que este contenido les sirva de referencia por si algún día se animan a incursionar en ello. No dejen de escuchar mi podcast a través de la principales plataformas de streaming (los enlaces de cada plataforma se los dejo a continuación). Si tienen comentarios o sugerencias no duden en hacérmelas llegar. Saludos y buena cuarentena.

Codalot en Spotify

Codalot en Podcast by Apple

Codalot en Google Play Music

Android — ¿Cómo evitar que los logs de tu app desaparezcan?

Armando Picón — Mon, 30 Sep 2019 22:44:11 +0000

Android — ¿Cómo evitar que los logs de tu app desaparezcan?

Quizá muchos ya sabían sobre esto, pero cuando uno emplear Logcat desde Android Studio y nuestra app sufre un crash los logs se reinician.

Esta situación se debe a que con la configuración por defecto Android Studio nos mostrará los logs solo del proceso seleccionado y cuando el proceso se muere (cuando nuestra app crashea) deja de registrar los logs.

Sin embargo, esto se puede evitar haciendo lo siguiente:

En la parte superior derecha de esta sección desplegamos la lista en la que suele estar seleccionada la opción Show only selected application y elegimos la opción Edit Filter Configuration.
A continuación, crearemos un nuevo filtro y en el campo Package Name colocaremos el nombre del paquete que querramos loguear (Ej. dev.picon.android.myapp )

Y listo! Esta configuración será suficiente para que por más que se muera nuestra app los logs continúen siendo visibles para nosotros.

Android — ¿Por qué no estás escribiendo tests? (1)

Armando Picón — Mon, 19 Aug 2019 03:45:11 +0000

Picture by @devpicon

Android — ¿Por qué no estás escribiendo tests? (1)

Be clean, be testeable

Es un tema recurrente año tras año: un buen número de desarrolladores no escriben tests (pruebas) para sus aplicaciones y las razones puede ser diversas: Desde “no sé cómo escribir tests” hasta “escribir tests me quita tiempo”. Siempre habrá razones para no escribir tests.

Y, por el contrario, siempre habrá buenas razones para escribir tests.

Los tests siempre harán tu código más fiable aumentando tu certeza de que lo que estás programando, efectivamente, cumple su propósito.
Contar con tests te ayudará a saber si alguna modificación introducida posteriormente rompe alguna otra funcionalidad de tu aplicación.
Evitar el “titánico” esfuerzo de mantenimiento de código que suele haber cuando no hay tests. El tiempo es dinero.

En este primer artículo desarrollaré un poco la parte teórica y ciertos lineamientos a tener en cuenta al momento de querer introducir tests en una aplicación con código legacy.

¿Qué puedo hacer para hacer mi código “testeable”?

Aunque en la vida uno vive escuchando de cuando en cuando acerca de los tests y lo impresionante que son, creo que pocos realmente te orientan a hallar un proceso para hacer tu código testeable.

The Test Pyramid

Partamos por algo básico y que seguramente ya han visto antes “la pirámide de los tests”.

La “Pirámide de los Tests_” es una metáfora que nos hace lleva a agrupar las pruebas de software en bloques de diferente granularidad. También, nos brinda una idea de cuántas pruebas deberíamos tener en dichos grupos. A pesar de que el concepto de la Pirámide de los_ Tests _ha estado presente por buen tiempo, los equipos siguen entrampados en cómo ponerlo en práctica. — _The Practical Test Pyramid (traducción libre)

Para no entrar en mucha discusión respecto a la pirámide, la figura se puede interpretar de la siguiente manera:

_Unit Tests — _la base está conformada por pruebas unitarias; estas son menos costosas y si tuvieramos que priorizar el esfuerzo para escribir pruebas debería ser en este bloque, principalmente, porque no hay una dependencia fuerte con frameworks y bibliotecas de código.

Service Tests—_el bloque del medio no se refiere solo a probar servicios; en realidad implica probar la integración entre componentes y las diferentes capas de nuestra aplicación. La priorización en esfuerzo es media, lo cual implica que el desarrollo de estas pruebas cuenta con una menor prioridad que los _unit tests.

_User Interface Tests — _finalmente, en la cúspide de nuestra pirámide se encuentran las pruebas de UI. El desarrollo de pruebas de UI guarda consigo cierta complejidad dependiendo de la aplicación que estemos probando. Proporcionalmente hablando, en muchos casos la cantidad de pruebas será menor que la de las otras capas.

Partamos con los “Unit Tests”

Un buen punto de inicio es comenzar a escribir unit tests (pruebas unitarias). Estas pruebas tienen como objetivo verificar el comportamiento de las funciones y la lógica de nuestras unidades de programación, las clases.

Como hablamos antes, se suele asumir que todos saben cómo hacerlas y, por ello, no se suele marcar un camino para llegar a ellas, pero en esta ocasión vamos a trazar algunos lineamientos y, posteriormente, lo traduciremos en una serie de tareas a seguir.

Las funciones y clases como mínimo deben cumplir con algunos de los principios SOLID: The Single Responsibility (Responsabilidad simple) que nos menciona que una clase debería tomar responsabilidad sobre una sola parte de nuestra aplicación; Interface Segregation (Segregación de interfaces) que implica que varias funcionalidades podrían estar definidas en varias abstracciones en lugar de una sola y, Dependency Inversion (Inversión de dependencia) que implica evitar el acoplamiento entre clases a través de generar dependencias sobre abstracciones.
Cuando una clase o función no cumpla con lo anterior, será una buena razón para comenzar a refactorizar, en un principio no haremos grandes cambios al diseño de la aplicación sino que comenzaremos a dividir funciones con múltiples responsabilidades en funciones de una sola responsabilidad. De ese modo separaremos nuestra lógica en funciones más pequeñas o incluso las terminaremos moviendo hacia otras clases.
Nuestros unit tests seguirán la estructura Given-When-Then, una estructura que tomaremos prestada de BDD y que se traduciría de la siguiente manera: “Dado (Given) un estado de nuestro componente o Dada alguna condición; Cuando (When) una acción se realiza o se invoca a una función con un conjunto de parámetros; Entonces (Then) deberíamos obtener un resultado esperado”.
Si hicimos bien la refactorización señalada en el punto 2, podremos mockear cualquier dependencia de la clase que queramos probar. Cuando me refiero a mockear, me refiero a que cualquier dependencia las podemos inflar o crear haciendo uso de una abstracción en conjunto con una concreción propia.

Bueno, teniendo esto en mente, en el siguiente artículo traduciré estos lineamientos a un ejercicio más práctico.

Referencias

The Practical Test Pyramid — https://martinfowler.com/articles/practical-test-pyramid.html
GivenWhenThen — https://martinfowler.com/bliki/GivenWhenThen.html
SOLID Principles: Explanation and examples — https://itnext.io/solid-principles-explanation-and-examples-715b975dcad4

Kotlin - ¿Funciones como operadores aritméticos? Sí, con Infix functions

Armando Picón — Tue, 11 Jun 2019 14:32:40 +0000

Trabajando algunas cosas como operadores

Esta es una adaptación libre basado en el artículo en inglés “Infix functions in Kotlin — Making Tuenti” escrito por Arturo Gutierrez.

Cuando escribes una función regular o una Extension Function, es posible emplearlas con la notación de infijo (o infix notation en inglés).

Vamos a armar un breve ejemplo que nos ayude a entender los infix functions.

Definamos algunos enumeradores y una clase:

enum class ZodiacSign {
    ARIES, TAURUS, GEMINI, CANCER, LEO, VIRGO, LIBRA, 
    SCORPIO, SAGITTARIUS, CAPRICORN, AQUARIUS, PISCES  
}

enum class Saint {
    MU, ALDEBARAN, SAGA, KANON, DEATHMASK, AIORIA, SHAKA, DOHKO, 
    MILO, AIOROS, SHURA, CAMUS, AFRODITA  
}

data class GoldenSaint( val saint : Saint, val zodiacSign : ZodiacSign)

Los nombres son muy explícitos, pero por si las dudas, se refiere a los signos zodiacales y los nombres de los caballeros dorados de un conocido dibujo japonés llamado “Caballeros del Zodiaco” (o Saint Seiya).

Si precisaramos crear un nuevo objeto la sintaxis habitual sería la siguiente:

    val virgoGoldenSaint = GoldenSaint(Saint. SHURA, ZodiacSign. VIRGO )

La idea es simplificar la forma de crear un nuevo objeto agregando una función al enum class Saint.

enum class Saint {
    MU, ALDEBARAN, SAGA, KANON, DEATHMASK, AIORIA, SHAKA, 
    DOHKO, MILO, AIOROS, SHURA, CAMUS, AFRODITA;

    fun of(zodiacSign: ZodiacSign) = GoldenSaint( this, zodiacSign)
}

Con la función of ganamos un poco de legibilidad a la creación de un objeto.

    val sagittariusGoldenSaint = Saint. AIOROS.of(ZodiacSign. SAGITTARIUS )

Podríamos mejorarla un poco más mediante la importación estática de cada elemento.

    val sagittariusGoldenSaint = AIOROS.of( SAGITTARIUS )

Hasta allí va luciendo mejor, pero aún se podría mejorar. Para ello le agregaremos la palabra reservada infix previo al nombre de nuestra función de esta manera:

enum class Saint {
    MU, ALDEBARAN, SAGA, KANON, DEATHMASK, AIORIA, 
    SHAKA, DOHKO, MILO, AIOROS, SHURA, CAMUS, AFRODITA;

    infix fun of(zodiacSign: ZodiacSign) = GoldenSaint( this, zodiacSign)
}

¿Y qué conseguimos con ello? Darle a la función una forma similar a la de un operador aritmético tal como lo podemos ver a continuación:

    val sagittariusGoldenSaint = AIOROS of SAGITTARIUS

¿Luce mejor verdad? Esto constituye un acercamiento a un lenguaje más natural haciendo nuestro código más legible y conciso.

Consideraciones

Algunas consideraciones para aplicar infix son las siguientes:

Puede aplicarse a extension functions y funciones de clase.
La función solo puede recibir un único parámetro.

P.D.

Puede encontrar más artículos sobre Kotlin en la publicación Kotlin Dev Reactor.

Referencias:

¡Gracias por leer el artículo, significa mucho para mi! Si lo disfrutaste o fue de utilidad por favor recomiéndalo y compartelo con tus amigos.

Me puedes encontrar en Twitter, Github y LinkedIn.

¿Qué nos dejó el Google I/O 2019?

Armando Picón — Mon, 13 May 2019 04:32:17 +0000

Para un Android Developer

Sin duda ha sido una edición interesante la de este año donde, a mi entender, hay mucho por procesar; en particular, si eres Android Developer.

Una foto con la banda latinoamericana en el Google I/O 2019

Por cuarta ocasión tuve la oportunidad de asistir al Google I/O que se viene dando en el Shoreline Amphitheatre, lugar en el que en medio de un ambiente de fiesta se presentan las diferentes novedades respecto a tecnologías que desarrolla Google.

El evento contó con sesiones que se desarrollaron en diversos espacios en conjunto con el anfiteatro, además de espacios temáticos en los que se podía conversar con ingenieros que vienen desarrollando diversas tecnologías: Android , Fluter+AR , Android Auto , Chrome OS , Wear OS , Firebase , Assistant , etc. Adicionalmente, hubo un espacio para los App Reviews y los Office Hour.

Las sesiones del evento ya se encuentran disponibles en el canal de Google Developers.

A continuación, comentaré un poco sobre las sesiones que tuve oportunidad de asistir.

Google Keynote

Algunas cosas que debo resaltar del keynote son las siguientes:

Hoy en día Google viene trabajando de la mano con la medicina para la detección temprana del cáncer mediante uso de modelos e inteligencia artificial.
El proyecto Duplex sigue avanzando, ahora no solo permitirá que nuestro asistente pueda interactuar con personas en la vida real para efectuar reservas, atender llamadas cuando estamos ocupados, etc. sino que también podrá interactuar automáticamente con webs para realizar operaciones que nos quitan tiempo.
Hay avances en cuestión de accesibilidad, ahora será posible contar con comunicaciones con transcripciones en vivo.
Proyecto Euphonia (http://g.co/euphonia) es un proyecto que emplea modelos entrenados para personas con dificultades de habla.

Se mostró el uso de herramientas como Google Translator y su capacidad de uso en mercados emergentes con dispositivos de bajo costo y bajas prestaciones. Es increíble la capacidad de compactar todos estos modelos para que su uso no requiera tanto espacio de almacenamiento.

Developer Keynote

Tras lo visto en el Google Keynote, nos tocó presenciar el Keynote para developers el cual toca aspectos más técnicos de las herramientas de Google. En esta ocasión esta keynote fue abierta por Thomas Kurian, actual CEO de Google Cloud. Si bien la keynote habla sobre varias tecnologías, me enfocaré en los anuncios hechos para Android.

Android pasa a tornarse Kotlin-first con mayor fuerza que antes y por ello muchas de las actualizaciones en las bibliotecas que componen Jetpack vendrán enfocadas en dicho lenguaje.
Se agregó un nuevo API a Jetpack llamado CameraX que busca estandarizar las implementaciones de cámaras de forma retrocompatible y hasta un 90% de dispositivos en le mercado.
También, se está trabajando una biblioteca llamada Jetpack Compose (en desarrollo) que permitirá un desarrollo reactivo de cara a la UI.
El equipo detrás de Android Studio realizó un feature freeze y se puso a trabajar sobre los bugs más importantes y a mejorar todas las herramientas desde sus bases, estas mejoras vendrán como parte de la versión 3.5.
Habrá una nueva característica llamada in-app updates que permitirá realizar actualizaciones de nuestras aplicaciones sin la necesidad de esperar a que la actualización provenga desde la Play Store.

Otras sesiones que vi

A continuación, les dejaré la lista de sesiones a las que tuve ocasión de asistir:

Aunque es una charla de introducción, nos trae las novedades que hay en Android.

En esta plática se nos explica cómo trabaja Kotlin por detrás.

En esta plática se nos explica cómo trabaja el nuevo API CameraX.

Me encantó esta plática que dieron Florina Muntenescu y Yigit Boyar, en la que juntos exploran diversos modelos de arquitectura en función al enfoque que uno le quiera dar. La lección final es “no te diremos cuál usar, todo dependerá de la aplicación que estés construyendo”, sin embargo, es una charla recomendable para ver porque te van mostrando los diversos aspectos que involucran el elegir y seguir el camino hacia el establecimiento de una arquitectura. Mi percepción sobre esta plática es que de tanto ver a la comunidad discutir sobre la arquitectura que uno debe emplear, quisieron dejar clara su posición al respecto.

Esta plática comienza con el repaso de los principios que rigen a las corutinas y luego va más allá, terminan mostrándonos como diversos componentes toman las corutinas y las integran para mejorar su funcionamiento.

La clásica charla con los responsables de cada equipo involucrado con el desarrollo de Android.

Si queremos ir un poco más a fondo de cómo trabaja Android, esta charla es buenísima. Nos ayuda a tener una mejor comprensión de cómo trabaja la maquina virtual de Android.

Pues hasta aquí con las pláticas a las que pude asistir, me quedaron varias pendientes que espero ir revisando en los próximos días. No dejen de revisarlas y seguir aprendiendo.

BTW Me quedé con las ganas de conseguir un Pixel 3a y un Smartwatch con Wear OS, pero ya será para una próxima ocasión.