de 2009 • Muy buenos motivos para que decidir que las apps Android se hagan en Java. • ¿Qué pasa con las decisiones de diseño que tomamos hace 10 años?
son difíciles de cambiar. • El SDK de Android está fuertemente basado en el concepto de herencia. • Reemplazo de componentes del SDK por librerías. • Retrocompatibilidad. • ¿Y los métodos ya existentes?
las APIs originales y logra un código Kotlin más idiomático. • Se distribuye en distintas librerías, organizadas por módulos: ◦ Core KTX. ◦ Fragment KTX. ◦ SQLite KTX. ◦ Collection KTX. ◦ ...
a una clase sin tener que modificarla. ◦ Evita la herencia. ◦ No es necesario tener acceso al código fuente de la clase que se va a extender. • Las funciones que se agregan se usan de la misma forma que cualquier otra función de la clase.
.kt que pueden ser usadas desde cualquier parte del proyecto ◦ Su visibilidad es acorde al modificador de acceso. ◦ Es necesario importar la función que se quiera usar.
for ((key, value) in pairs) { when (value) { null -> putString(key, null) // Any nullable type will suffice. // Scalars is Boolean -> putBoolean(key, value) is Byte -> putByte(key, value) … …
parámetros y es difícil recordar el orden de los mismos. • Mismo problema cuando los parámetros son del mismo tipo. • Agregan claridad y legibilidad al poder llamar a cada parámetro por su nombre.
pasarse como parámetro, asignar a una variable, etc. • Útiles cuando se quiere mandar una callback como parámetro. • También son útiles cuando siempre es necesaria una inicialización y finalización antes de realizar una tarea.