Publicado por Hoi Lam, ingeniero de relaciones con desarrolladores para la Plataforma de Android
En 2021, seguiremos trabajando en nuestra actualización anual de nivel de API de destino, que les solicitará a las nuevas apps en agosto, y a todas las actualizaciones de apps en noviembre, que se orienten al nivel de API 30 (Android 11). Además, como anunciamos a principios de este año, Google Play les solicitará a las apps nuevas que usen el formato de pubilcación de Android App Bundle. Este trae los beneficios de las apps más pequeñas y los lanzamientos más simples a más usuarios y desarrolladores, y apoya las inversiones continuas en distribución avanzada.
Publicado por Hoi Lam, ingeniero de relaciones con desarrolladores para la Plataforma de Android
En 2021, seguiremos trabajando en nuestra actualización anual de nivel de API de destino, que les solicitará a las nuevas apps en agosto, y a todas las actualizaciones de apps en noviembre, que se orienten al nivel de API 30 (Android 11). Además, como anunciamos a principios de este año, Google Play les solicitará a las apps nuevas que usen el formato de pubilcación de Android App Bundle. Este trae los beneficios de las apps más pequeñas y los lanzamientos más simples a más usuarios y desarrolladores, y apoya las inversiones continuas en distribución avanzada.
Más de 750 000 apps y juegos ya se publican en etapa de producción en Google Play usando paquetes de aplicaciones. Las principales apps que realizaron el cambio ahorraron en promedio un 15% en su tamaño, en comparación con el uso de un APK universal. Los usuarios se beneficiaron con las descargas más pequeñas, y los desarrolladores, como Netflix y Riafy, notaron un aumento en sus tasas de éxito de instalaciones, lo cual tiene un mayor impacto en las regiones con más dispositivos de gama baja y velocidades de datos más lentas. Los desarrolladores que implementaron el cambio pueden usar funciones de distribución avanzada, como Play Asset Delivery y Play Feature Delivery. Valoramos mucho sus comentarios y planeamos incluir más funciones y opciones para Firma de apps de Play y paquetes Android App Bundle antes de implementar el cambio.
Requisitos para las apps nuevas
A partir de agosto de 2021, Google៕ Play Console les solicitará a todas las apps nuevas lo siguiente:
Usar Play Asset Delivery o Play Feature Delivery para publicar elementos o funciones cuyos tamaños de descarga excedan los 150 MB (ya no se admiten los archivos de expansión, OBB, para las apps nuevas)
Orientarse al nivel de API 30 (Android 11) o uno posterior y ajustarse a los cambios de comportamiento
Requisitos para las actualizaciones de apps existentes
A partir de noviembre de 2021, las actualizaciones de apps existentes deberán orientarse al nivel de API 30 o uno posterior y ajustarse a los cambios de comportamiento de Android 11. Las apps existentes que no reciban actualizaciones no se verán afectadas y se podrán seguir descargando desde Play Store.
Requisitos para experiencias instantáneas
El cambio a la publicación con Android App Bundle también impactará en las experiencias instantáneas que usan el formato ZIP para apps instantáneas heredado. A partir de agosto de 2021, las experiencias instantáneas nuevas y las actualizaciones de las existentes deberán publicar paquetes de aplicaciones instantáneas.
Las apps de Wear OS no están sujetas al nuevo requisito de nivel de API de destino.
Las apps todavía podrán usar cualquier minSdkVersion, así que no habrá cambios en tu capacidad de compilar aplicaciones para versiones anteriores de Android.
Para obtener más información sobre la transición a paquetes de apps, mira nuestra nueva serie de video: modern Android development (MAD) skills (habilidades para el desarrollo moderno de Android). Agradecemos sumamente a todos los desarrolladores que ya adoptaron los paquetes de apps y se orientaron al nivel de API 30. Esperamos seguir mejorando la plataforma de Android junto a ustedes.
Término clave: Esto significa que la versión HTTP insegura de un sitio, por ejemplo, http://website.example, y la versión HTTPS segura de ese sitio, https://website.example, ahora se consideran entre sitios.
La buena noticia es que, si tu sitio web ya fue totalmente actualizado a HTTPS, no necesitas preocuparte por nada. Nada cambiará para ti.
Si todavía no has actualizado totalmente tu sitio web, esa debería ser tu prioridad. Sin embargo, si hay casos en los que los visitantes de tu sitio van a elegir entre HTTP y HTTPS, algunos de esos escenarios comunes y el comportamiento de las cookies SameSite asociadas se describen a continuación.
Advertencia: El plan a largo plazo es eliminar gradualmente la asistencia a cookies de terceros por completo y reemplazarlas con alternativas que preserven la privacidad. Configurar SameSite=None; Secure en una cookie para permitir que se envíe entre esquemas solo debería considerarse una solución temporal en la migración hacia el HTTPS completo.
Puedes habilitar estos cambios para realizar la prueba tanto en Chrome como en Firefox.
Desde Chrome 86, habilita chrome://flags/#schemeful-same-site. Realiza un seguimiento del progreso en la página de estado de Chrome.
Desde Firefox 79, configura network.cookie.sameSite.schemeful como true mediante about:config. Realiza un seguimiento del progreso mediante la edición Bugzilla.
Una de las razones principales para cambiar a SameSite=Lax como la configuración predeterminada para cookies fue protegerse contra la falsificación de solicitudes entre sitios (CSRF). Sin embargo, el tráfico HTTP inseguro aún presenta una oportunidad para que los atacantes de la red falsifiquen las cookies que, luego, serán usadas en la versión HTTPS segura del sitio. Crear este límite entre sitios adicional entre esquemas proporciona una mayor defensa ante estos ataques.
Término clave: En los siguientes ejemplos en los que las URL tienen el mismo dominio registrable, p. ej., site.example, pero diferentes esquemas, por ejemplo, http://site.example frente a https://site.example, se utiliza la denominación entre esquemas.
Navegar entre versiones entre esquemas de un sitio web (por ejemplo, establecer vínculos desde http://site.example y https://site.example) antes permitía que se enviaran cookies SameSite=Strict. Ahora, esto se trata como una navegación entre sitios, lo que significa que las cookies SameSite=Strict se bloquearán.
Advertencia: Todos los navegadores populares bloquean el contenido mixto activo como las secuencias de comando y los iframes. Además, los navegadores, incluidos Chrome y Firefox, trabajan para lograr la actualización o el bloqueo del contenido mixto pasivo.
Cualquier cambio que hagas aquí se considerará una solución temporal mientras trabajas para actualizar por completo a HTTPS.
Entre los ejemplos de subrecursos, se incluyen imágenes, iframes y solicitudes de red realizadas con XHR o Fetch.
Antes, cargar un subrecurso entre esquemas en una página habría permitido que las cookies SameSite=Strict o SameSite=Lax se enviaran o configuraran. Ahora, esto se trata de la misma forma que cualquier otro subrecurso de terceros o entre sitios, lo que significa que cualquier cookie SameSite=Strict o SameSite=Lax se bloqueará.
Además, incluso si el navegador permite que se carguen recursos de esquemas inseguros en una página segura, se bloquearán todas las cookies en estas solicitudes, ya que las cookies de terceros o entre sitios requieren Secure.
Una página HTTP que incluye un subrecurso entre esquemas mediante HTTPS.
Antes, publicar entre versiones entre esquemas de un sitio permitía que las cookies configuradas con SameSite=Lax o SameSite=Strict se enviaran. Ahora, esto se trata como una publicación entre sitios: solo pueden enviarse cookies SameSite=None. Tal vez encuentres este escenario en sitios que presentan la versión insegura de manera predeterminada, pero los usuarios se actualizan a la versión segura al enviar el formulario de acceso o salida.
Como ocurre con los subrecursos, si la solicitud va de un contexto seguro, p. ej., HTTPS, a uno inseguro, p. ej., HTTP, se bloquearán todas las cookies en estas solicitudes, ya que las cookies de terceros o entre sitios requieren Secure.
Advertencia: La mejor solución aquí es asegurar que tanto la página de formulario como el destino estén en una conexión segura como HTTPS. Esto es particularmente importante si el usuario está ingresando información confidencial en el formulario.
Envío de formulario entre esquemas de HTTP a HTTPS.
Las herramientas para desarrolladores y la mensajería están disponibles en Chrome y Firefox.
Desde Chrome 86, la pestaña Error en DevTools incluirá errores Schemeful Same-Site. Puedes ver los siguientes errores destacados para tu sitio.
Errores de navegación:
«Migrar por completo a HTTPS para que las cookies se sigan enviando en solicitudes del mismo sitio» es una advertencia de que la cookie se bloqueará en una versión futura de Chrome.
«Migrar por completo a HTTPS para que las cookies se envíen en solicitudes del mismo sitio» es una advertencia de que la cookie se ha bloqueado.
Errores de carga de subrecursos:
«Migrar por completo a HTTPS para que las cookies se sigan enviando en subrecursos del mismo sitio» o «Migrar por completo a HTTPS para seguir permitiendo que las cookies se envíen a subrecursos del mismo sitio» son advertencias de que la cookie se bloqueará en una versión futura de Chrome.
«Migrar por completo a HTTPS para que las cookies se envíen a subrecursos del mismo sitio» o «Migrar por completo a HTTPS para permitir que las cookies se envíen mediante subrecursos del mismo sitio» son advertencias de que la cookie se ha bloqueado. Esta última advertencia también puede aparecer al publicar un formulario.
Desde Firefox 79, con network.cookie.sameSite.schemeful configurado como true mediante about:config, la consola mostrará un mensaje para los errores de Schemeful Same-Site. Tal vez veas lo siguiente en tu sitio:
«La cookie cookie_namepronto se tratará como una cookie entre sitios en oposición a http://site.example/ porque el esquema no coincide».
«La cookie cookie_namese ha tratado como entre sitios en oposición a http://site.example/ porque el esquema no coincide».
Mi sitio ya está disponible por completo en HTTPS; ¿por qué veo errores en DevTools de mi navegador? #
Es posible que algunos de tus vínculos y sus recursos aún apunten a URL inseguras.
Una forma de solucionar este error es usar HTTP con Seguridad de Transporte Estricta (HSTS) y la directiva includeSubDomain. Con HSTS + includeSubDomain, incluso si una de tus páginas incluye un vínculo inseguro por accidente, el navegador usará en su lugar la versión segura automáticamente.
Si bien recomendamos enfáticamente que actualices tu sitio completo a HTTPS para proteger a tus usuarios, si no puedes hacerlo solo, te sugerimos que hables con tu proveedor de hosting para ver si te ofrece esa opción. Si usas tu propio host, entonces Let's Encrypt proporciona herramientas para instalar y configurar un certificado. También puedes investigar la posibilidad de mover tu sitio a CDN o a otro proxy que pueda proporcionar la conexión HTTPS.
Si eso tampoco es posible, intenta disminuir la protección SameSite en las cookies afectadas.
En los casos donde solo las cookies SameSite=Strict se bloquean, puedes disminuir la protección a Lax.
En los casos donde tanto las cookies Strict como Lax se bloquean y tus cookies se envían a una URL segura o se configuran desde una, puedes disminuir las protecciones a None.
Esta solución alternativa fallará si la URL a la que envías las cookies (o desde donde las configuras) es insegura. Esto se debe a que SameSite=None requiere el atributo Secure en las cookies, lo cual significa que esas cookies podrían no enviarse ni configurarse a través de una conexión insegura. En ese caso, no podrás acceder a esa cookie hasta que tu sitio se actualice a HTTPS.
Recuerda que esto es solo temporal, ya que las cookies de terceros se eliminarán por completo.
¿Cómo afecta esto a mis cookies si no especifiqué un atributo SameSite? #
Las cookies sin un atributo SameSite se tratan como si especificaran SameSite=Lax y el mismo comportamiento entre esquemas se aplica a ellas. Ten en cuenta que la excepción temporal para métodos poco seguros aún se aplica. Para obtener más información, consulta la mitigación Lax + POST en las preguntas frecuentes de ChromiumSameSite.
Publicado por Andrew Ahn, gerente de Productos, seguridad de apps de Google Play
En Google Play queremos fomentar un ecosistema de apps seguras, atractivas, útiles y entretenidas para que miles de millones de usuarios de Android de todo el mundo las usen y las adoren. Por esta razón, actualizamos y revisamos con regularidad nuestras Políticas para Desarrolladores de Google Play y el Acuerdo de Distribución para Desarrolladores, y detallamos cuáles son los límites del contenido y de las funciones de las apps que se permiten en la plataforma. Además, brindamos a los desarrolladores información actualizada sobre cómo promocionar y monetizar sus apps.
Publicado por Andrew Ahn, gerente de Productos, seguridad de apps de Google Play
En Google Play queremos fomentar un ecosistema de apps seguras, atractivas, útiles y entretenidas para que miles de millones de usuarios de Android de todo el mundo las usen y las adoren. Por esta razón, actualizamos y revisamos con regularidad nuestras Políticas para Desarrolladores de Google Play y el Acuerdo de Distribución para Desarrolladores, y detallamos cuáles son los límites del contenido y de las funciones de las apps que se permiten en la plataforma. Además, brindamos a los desarrolladores información actualizada sobre cómo promocionar y monetizar sus apps.
En nuestros esfuerzos recientes para verificar si las apps cumplían con las políticas de Google Play, identificamos algunos incumplimientos y errores comunes que cometen los desarrolladores, y queremos acercarle a esta comunidad sugerencias y pautas para que los eviten. De esta manera, podremos mitigar los riesgos de suspensión de las cuentas y apps de desarrolladores por infringir nuestras políticas.
Vínculos que dirigen a los usuarios a otras apps de Play Store
Uno de los errores más frecuentes que observamos está relacionado con apps que tienen botones y menús vinculados con Play Store, ya sea que dirigen a apps del mismo desarrollador o están afiliadas a este, pero no queda claro si son anuncios o vínculos promocionales. Ese tipo de confusión puede conducir al bloqueo de las apps por contener anuncios engañosos o encubiertos. Una de las alternativas para evitar estos errores es asignar a los botones y los vínculos etiquetas explícitas como “Más aplicaciones”, “Más juegos”, “Explorar”, “Consulta nuestras otras aplicaciones”, etc.
Ejemplo de contenido de una app vinculado a la ficha de una app en Play
Descripciones de apps con spam
Otro de los errores que observamos con frecuencia se presenta cuando los desarrolladores incluyen a propósito palabras clave en la descripción de la app para mejorar la visibilidad y clasificación respecto de ciertas palabras clave y frases. Los bloques de texto o las listas que contienen referencias y palabras clave repetitivas o que no están relacionadas infringen nuestra política de promociones y fichas en Store. Una de las mejores opciones para evitar cometer este tipo de infracción es escribir una descripción de la app clara y optimizada para propiciar la legibilidad y comprensión por parte del usuario.
Mira este video para aprender a evitar la fichas de la tienda que tengan spam y los esfuerzos para mejorar de forma artificial la visibilidad de la app.
Apps abandonadas y con fallas
Existen apps que los desarrolladores publicaron hace mucho tiempo, pero nunca actualizaron. Las apps abandonadas y desactualizadas suelen presentar inconvenientes relacionados con la experiencia del usuario; por ejemplo, fallas en la funcionalidad de una app. Esas apps corren el riesgo de recibir una calificación por estrellas baja y opiniones negativas de los usuarios, y se marcarán para indicar que no cumplen con la política de funcionalidad mínima. Considera quitar esas apps de Play Store para reducir el impacto negativo que producen en la reputación del desarrollador y la implementación de la app. Ten en cuenta que esta acción no afectará a los usuarios existentes que ya instalaron la app, y los desarrolladores siempre podrán volver a publicar sus apps después de corregir las fallas.
Ejemplo de una app abandonada que presenta una experiencia con errores
Por último, observamos que hay un gran volumen de propuestas de apps que solo son vistas web de sitios web existentes. El objetivo principal de la mayoría de estas solicitudes es dirigir tráfico en lugar de crear experiencias de apps atractivas para los usuarios de Android. Estas apps se consideran vistas web con spam y se quitan de Play. Piensa qué pueden realizar o hacer mejor los usuarios con tu app en comparación con una experiencia web, y considera implementar características y funciones pertinentes que enriquezcan la experiencia del usuario.
Ejemplo de una vista web sin funcionalidades de app
Paquetes de apps, versiones estables de AndroidX, artículos y videos de Kotlin y un nuevo episodio del podcast de ADB
Te damos la bienvenida a Now in Android, una guía que actualizamos constantemente con las novedades más importantes sobre el desarrollo de Android.
MAD Skills: Paquetes de apps
La serie de MAD Skills continúa, con contenido técnico sobre el desarrollo moderno de Android. Wojtek Kaliciński y Ben Weiss publicaron algunos episodios en la segunda serie sobre paquetes de apps. Hasta ahora, vimos contenido acerca de la firma de apps de Play, cómo crear tu primer paquete de apps y Play Feature Delivery. Mira los videos y artículos que aparecen a continuación para obtener más información.
Episodio 1: todo lo que debes saber acerca de la firma de apps de Play
En una serie sobre paquetes de Android, es normal hablar de la firma de apps, porque Play genera APK para descargar en los dispositivos de los usuarios, y esos APK se deben firmar para su instalación. En este video, se detallan los pasos que se deben seguir para habilitar la firma de una app en Play Console, incluidas las opciones para subir tu propia clave o que Google genere una.
Asegúrate de consultar el artículo relacionado de Wojtek sobre las preguntas comunes acerca de la firma de apps de Play:
En el video de Ben, se detallan los pasos que debes seguir para crear un paquete de apps, ya sea en Android Studio o en la línea de comandos, para luego subirlo a Play Console. Además, Ben muestra cómo usar herramientas en Play Console para buscar información sobre el paquete subido.
Episodio 3: cómo configurar tu app para Play Feature Delivery
En este episodio, se muestra cómo usar Android Studio para dividir tu aplicación en módulos y cómo seleccionarlos para descargarlos al momento de la instalación (con condiciones opcionales para determinar si se instalarán o no) o a pedido. Ben también proporciona más detalles sobre la manera de usar las API para solicitar la instalación de módulos a pedido.
Episodio 4: cómo realizar pruebas con bundletool y Play Console
En este último episodio, Wojtek explica cómo usar las herramientas disponibles para probar tu paquete y los APK resultantes, incluida bundletool para pruebas locales y Play Console para probar las cargas.
En la descripción del video, hay varios artículos y documentos vinculados. Asegúrate de consultarlos para obtener más información sobre el tema.
No te pierdas el contenido final de App Bundles la próxima semana. Haremos una sesión de preguntas y respuestas en vivo el próximo jueves (en ese momento, aparecerá un enlace a la transmisión en vivo por YouTube en la lista de reproducción, pero antes abriremos una publicación de preguntas por Twitter).
Entre la gran variedad de versiones alfa, beta y RC de las bibliotecas de AndroidX, recientemente se lanzaron algunas importantes versiones estables sobre las que me gustaría contarte.
ConstraintLayout 2.0.4: el cambio más significativo fue en la versión 2.0.2 (también reciente), que incluyó optimizaciones importantes sobre el rendimiento. Pero te recomiendo obtener la última versión con las correcciones de errores adicionales desde entonces. Las mejoras en el rendimiento provienen de ConstraintLayout, que ahora es mucho más inteligente y sabe cuándo puede omitir la ejecución del solucionador y evitar varias pasadas de este y de mediciones. Esto permite muchos beneficios en el rendimiento en varias situaciones habituales. Por ejemplo, las jerarquías que tienen muchísimas vistas GONE y vistas que usan restricciones en las coincidencias (layout_[height|width]=”0dp”) pueden ser mucho más rápidas para diseñar.
Startup 1.0.0: La biblioteca de App Startup se desarrolló para que las apps puedan inicializar componentes durante el inicio de una manera más fácil y óptima que la que podrían aplicar de otra forma. Resulta que inicializar un único objeto ContentProvider lleva una cantidad significativa de tiempo y muchas apps inicializan más de uno de ellos; a menudo muchos más. Startup permite que las apps inicialicen componentes sin crear varios objetos ContentProvider (adelanto: la biblioteca crea y usa un solo ContentProvider bajo la superficie para todas las solicitudes), lo que permite que tu app omita la mayor parte de esa sobrecarga.
Tracing 1.0.0: esta biblioteca escribe eventos de seguimiento en el búfer de seguimiento del sistema. Si instrumentas tu app con eventos de seguimiento, podrás proporcionar mejor información sobre el rendimiento que la que puedes ver con la herramienta Perfetto (o Systrace en dispositivos más antiguos). Consulta la guía sobre seguimiento de sistemas para obtener más información al respecto. Esta biblioteca “nueva” no ofrece una nueva funcionalidad por sí misma, pero la proporciona desde la clase TraceCompat existente de manera muy específica para que no tengas que usar todo androidx.core para esta funcionalidad limitada. También hay una función de extensión de KTX útil que facilita la acción de agregar seguimiento a un determinado bloque de código.
Artículos y videos: Kotlin, Kotlin, Kotlin y más Kotlin
No siempre hablamos sobre Kotlin, pero cuando lo hacemos, hablamos mucho del tema. Recientemente, se publicaron varios artículos y videos acerca de Kotlin:
Datos con clase
Florina Muntenescu agregó otro episodio a la serie en curso de Vocabulario de Kotlin, esta vez sobre las clases de datos de Kotlin. Las clases de datos te permiten crear fácilmente una estructura para contener datos con menos código estándar y depender de Kotlin para que genere automáticamente funciones equals() y hashCode() adecuadas. Además, puedes acceder a la desestructuración de las propiedades de la clase desde un principio, junto con copy(). Como suele hacer con los episodios de Vocabulario de Kotlin, Florina analiza el código de bytes descompilado de las clases de datos para explicar el funcionamiento de todo en profundidad.
¿Debo aprender Kotlin para Android? (y otras preguntas frecuentes)
La respuesta es:"sí".
No obstante, para una explicación más completa, Florina publicó este artículo en el que responde algunas de las preguntas principales que recibimos por parte de desarrolladores sobre si invertir para aprender y desarrollar Kotlin, e incluye enlaces a recursos de aprendizaje importantes.
En este artículo, Florina analiza algunos de los motivos por los que las apps de Kotlin son menos propensas a generar errores que las apps que no se escriben en Kotlin. Ella señala algunas apps y casos de uso específicos que respaldan esta afirmación, pero también analiza algunos de los motivos por los que este lenguaje permite escribir un código más sólido, incluyendo la nulabilidad, hashCode() != equals() y mucho más. Consulta la publicación para conocer todos los detalles.
Desde la última edición de Now in Android, se publicó otro episodio de Android Developers Backstage. Accede al vínculo más abajo o escúchalo a través de tu cliente de podcast favorito:
ADB 152: Carga de imágenes con Coil
Romain Guy, Tor Norbye y yo hablamos con Colin White de Instacart sobre su biblioteca de carga de imágenes de código abierto, Coil. Conversamos sobre la carga de imágenes, el rendimiento, el código abierto y el uso de Kotlin y corrutinas para crear esta biblioteca basada en Kotlin.
Los usuarios esperan disfrutar de una experiencia fluida con tu app. Las fallas pueden producir un incremento en las opiniones negativas y las desinstalaciones e incluso dañar la percepción sobre tu producto. A partir del diálogo con la comunidad, sabemos que una de las razones principales para adoptar Kotlin es obtener un código más seguro. En esta publicación, compartiremos algunas de las maneras en que Kotlin mejoró la estabilidad de algunos de los códigos de nuestros socios y también observaremos los resultados de algunas de las estadísticas de Google Play Store y veremos si existe una correlación entre el uso de Kotlin y la cantidad de fallas (spoiler: ¡las hay!).
Los usuarios esperan disfrutar de una experiencia fluida con tu app. Las fallas pueden producir un incremento en las opiniones negativas y las desinstalaciones e incluso dañar la percepción sobre tu producto. A partir del diálogo con la comunidad, sabemos que una de las razones principales para adoptar Kotlin es obtener un código más seguro. En esta publicación, compartiremos algunas de las maneras en que Kotlin mejoró la estabilidad de algunos de los códigos de nuestros socios y también observaremos los resultados de algunas de las estadísticas de Google Play Store y veremos si existe una correlación entre el uso de Kotlin y la cantidad de fallas (spoiler: ¡las hay!).
Calidad de la app
La calidad de tu app no solo influye en la experiencia del usuario. Hay varios otros elementos que se verán afectados por una gran cantidad de fallas:
Visibilidad de la app: las recomendaciones de Google Play Store constan de una combinación de tratamiento humano y cálculos algorítmicos, de los cuales la calidad es una de las principales consideraciones.
Producto: el rendimiento de tu producto puede afectar las calificaciones y opiniones que recibas, lo que puede tener un impacto sobre la percepción de este.
Números más altos de usuarios (interesados): la mejora del tráfico orgánico y la percepción de la marca pueden generar una mejor captación y retención de usuarios, lo que también puede tener un impacto sobre la participación y las métricas de la parte inferior del embudo.
Las apps integradas con Kotlin tienen un 20 % menos de probabilidades de sufrir fallas.
¿Qué función desempeña Kotlin en esto? Analizamos las 1000 apps principales de Google Play y observamos que las que usan Kotlin tienen un 20 % menos de fallas por usuario que las que no lo hacen.
Un ejemplo de esto se puede hallar en el equipo de ingeniería de Swiggy, de cuyo código el 74 % está compilado en Kotlin; este equipo observó una reducción del 50 % en las fallas desde que el nuevo desarrollo de características pasó a Kotlin.
Cómo evitar NullPointerExceptions
La principal causa de fallas en Google Play son NullPointerExceptions. En 2018, el equipo de Google Home comenzó a escribir todas las nuevas características en Kotlin y observó una disminución del 33 % en las fallas de puntero nulo durante el plazo de un año.
Google Home observó una disminución del 33 % en las NullPointerExceptions
Para evitar NullPointerExceptions, debes asegurarte de que las referencias del objeto con el que estás trabajando sean no nulas antes de llamar a métodos para ellas o de intentar acceder a sus miembros. En Kotlin, la nulabilidad es parte del sistema de tipo. Por ejemplo, se debe declarar una variable como anulable o no anulable antes de comenzar. A la hora de convertir la parte de nulabilidad del sistema de tipo, no es necesario que recurras a lo que recuerdes o conozcas sobre la base de código ni a las advertencias de tiempo de compilación (si comentas tus campos y parámetros con @Nullable). Se aplica, más bien, la nulabilidad para que obtengas errores de tiempo de compilación y no solo advertencias. Para consultar maneras en las que puedes controlar la nulabilidad, visita esta página.
Cómo evitar problemas comunes
Los desarrolladores ingresan muchos problemas sin darse cuenta, y muchos de ellos pueden ser bastante sutiles y difíciles de investigar. Aquí hay algunos ejemplos de esta clase de problemas que se evitan cuando se usa Kotlin.
hashCode() y equals()
Si dos objetos son iguales, su hashcode debe ser el mismo; sin embargo, olvidarse de implementar uno de estos métodos o actualizarlos cuando se agregan nuevas propiedades a la clase es algo normal. Al trabajar con estas clases cuyas funciones son solo las de contener datos, usa las clases de datos de Kotlin. Con las clases de datos el compilador genera hashCode() y equals(), y estos se actualizan de forma automática cuando cambias las propiedades de las clases.
Comparación de igualdad estructural e igualdad referencial
¿Dos objetos son iguales a nivel estructural (tienen contenido equivalente) o iguales de forma referencial (sus punteros son los mismos)? En el lenguaje de programación Java, para los primitivos siempre debes usar ==; por lo tanto, un error común es también llamar == (igualdad referencial) a objetos, cuando lo que en verdad quieres es controlar si son iguales a nivel estructural (verificados al llamarlos equals()). Primero, Kotlin no tiene tipos primitivos, sino que usa clases como Int o String; esto significa que ya no es necesario que realices esta diferenciación entre objetos y tipos primitivos, puesto que todo es un objeto. Segundo, Kotlin definido == para igualdad estructural y === para igualdad referencial a fin de que no controles la igualdad referencial cuando no deberías.
Cuando "if else if else if else" no es suficiente
Cuando se trabaja con enums, con frecuencia necesitarás asegurarte de que estás cubriendo todos los casos posibles. Esto conduce a usar un interruptor o una cadena de varios "if else". Cuando modificas tu enum para agregar un nuevo valor, deberás controlar manualmente cada fragmento de código donde estés usando el enum y asegurarte de estar manejando el caso nuevo. Pero esto es propenso a errores. En Kotlin, puedes confiar que el compilador haga esto si estás usando el parámetro "when" como expresión: si no estás cubriendo todas las ramificaciones posibles, aparecerá un error del compilador.
Conclusión
La estabilidad de tu app es importante para tus usuarios y tu marca. Comienza a utilizar Kotlin para reducir las tasas de fallas, mantener a tus usuarios contentos y estar al tanto de tu retención y adquisición manteniendo una alta calificación de la app.
A cuatro meses del inicio oficial de la temporada DevFest 2020 confirmada para el 16, 17 y 18 de octubre, la idea de organizar un único evento que reuniera a todas las comunidades de LATAM era impensado. Sin embargo, nos propusimos lograr esta unión a pesar de la diversidad de culturas, países y formas de organización existentes. Perseguir este objetivo demandó un gran esfuerzo, compromiso y trabajo en equipo de la comunidad.
El primer paso fue incentivar la unidad para redefinirnos como una gran comunidad. Abandonar nuestras particularidades e identificarnos con una visión clara y amplia en pos de una meta colectiva: ser parte de la comunidad LATAM.
Conformamos equipos de trabajo que establecieron su propia planificación de tareas para cada área clave: Speakers & Agenda, Marketing & Design, Creative & Sponsors, Media & Transmissions y Web & Apps. Fijamos los viernes como el día de reunión semanal de todos los equipos para compartir avances, realizar el seguimiento de las actividades y motivarnos a seguir adelante con los planes previstos.
Comprender desde el inicio que toda forma de colaboración y apoyo sería valorada y agradecida en igual medida por todo el equipo, contribuyó a evitar juicios de valor y diferencias relacionadas con el nivel de participación y compromiso de los miembros durante la organización del evento.
El siguiente paso fue definir los objetivos y construir una base sólida para sustentar la organización del evento. Es por ello que decidimos centrarnos en los pilares básicos: speakers, streaming y difusión para luego sumar esfuerzos en otras áreas como sponsors y dinámicas del evento.
Dispuesto el branding oficial para DevFest 2020, fue necesario adaptarlo para reforzar su identificación con la región bajo el concepto de Latinoamérica unida.
Muy pronto descubrimos el talento de algunos miembros de la comunidad en otras áreas como diseño y edición de video. Como parte del equipo de Marketing & Design su aporte fue clave para la creación de los elementos gráficos necesarios, como así también su apoyo en la difusión y transmisión.
La tarea de construir un sitio web para reunir toda la información de DevFest LATAM estuvo a cargo del equipo de Web & Apps, integrado por organizadores entusiastas de Flutter.
El equipo asumió con éxito el reto de crear el sitio web oficial y las apps - disponibles para Android y iOS -, utilizando un mismo código.
EPÍGRAFE: Múltiples plataformas, el mismo código El sitio web y la app de DevFest LATAM fueron desarrolladas en Flutter
El contenido fue la estrella
Hacer un evento memorable con contenidos de calidad no fue una tarea sencilla. Organizamos un Call for Papers accesible al público en general, expertos de la industria y Google Developer Experts. Durante el proceso evaluamos las propuestas con imparcialidad, lo cual permitió garantizar su calidad. Realizamos rondas de evaluación, entrevistas y ofrecimos apoyo a los speakers.
Tal fue la expectativa generada, que recibimos propuestas de otros países y regiones, como Estados Unidos, Brasil y España. Con una mayor diversidad de idiomas, incluimos contenidos en español, inglés y portugués.
Luz, cámara, YouTube
Inicialmente, gracias a una experiencia de uso positiva en la transmisión de otros eventos de la comunidad, optamos por utilizar StreamYard.
Sin embargo, el canal de YouTube de Google Developers LATAM nos abrió sus puertas, brindó el soporte técnico necesario y la oportunidad de generar un mayor impacto regional con la transmisión del DevFest LATAM, lo cual nos motivó a maximizar los esfuerzos.
La experiencia DevFest más allá de lo virtual
El DevFest es un gran evento para disfrutar de buenas presentaciones, conocer e interactuar con otros miembros de la comunidad y participar en dinámicas divertidas. Pero, ¿cómo trasladar esta experiencia a un entorno virtual?
Decidimos que Discord era el mejor canal para expandir la experiencia de los asistentes: alentarlos a participar activamente, facilitar la interacción con los speakers después de cada presentación, realizar networking y asistir al after-party por cada día de evento.
Agradecimientos
Queremos agradecer a todos los integrantes del Equipo organizador del DevFest LATAM y a cada una de las comunidades de los distintos países que apoyaron en la difusión de este evento.
DevFest LATAM en números
3 días de evento
28 comunidades, 11 países diferentes de LATAM
2K asistentes registrados orgánicamente
10.8K de usuarios únicos durante los tres días de transmisión
14.7K Total Views
+36 ponentes
+ 32 hs. de transmisión en vivo
3 sesiones con transmisión simultánea
Contenidos en 3 idiomas (Español, Inglés y Portugués)
A cuatro meses del inicio oficial de la temporada DevFest 2020 confirmada para el 16, 17 y 18 de octubre, la idea de organizar un único evento que reuniera a todas las comunidades de LATAM era impensado. Sin embargo, nos propusimos lograr esta unión a pesar de la diversidad de culturas, países y formas de organización existentes. Perseguir este objetivo demandó un gran esfuerzo, compromiso y trabajo en equipo de la comunidad.
El primer paso fue incentivar la unidad para redefinirnos como una gran comunidad. Abandonar nuestras particularidades e identificarnos con una visión clara y amplia en pos de una meta colectiva: ser parte de la comunidad LATAM.
Conformamos equipos de trabajo que establecieron su propia planificación de tareas para cada área clave: Speakers & Agenda, Marketing & Design, Creative & Sponsors, Media & Transmissions y Web & Apps. Fijamos los viernes como el día de reunión semanal de todos los equipos para compartir avances, realizar el seguimiento de las actividades y motivarnos a seguir adelante con los planes previstos.
Comprender desde el inicio que toda forma de colaboración y apoyo sería valorada y agradecida en igual medida por todo el equipo, contribuyó a evitar juicios de valor y diferencias relacionadas con el nivel de participación y compromiso de los miembros durante la organización del evento.
El siguiente paso fue definir los objetivos y construir una base sólida para sustentar la organización del evento. Es por ello que decidimos centrarnos en los pilares básicos: speakers, streaming y difusión para luego sumar esfuerzos en otras áreas como sponsors y dinámicas del evento.
Dispuesto el branding oficial para DevFest 2020, fue necesario adaptarlo para reforzar su identificación con la región bajo el concepto de Latinoamérica unida.
Muy pronto descubrimos el talento de algunos miembros de la comunidad en otras áreas como diseño y edición de video. Como parte del equipo de Marketing & Design su aporte fue clave para la creación de los elementos gráficos necesarios, como así también su apoyo en la difusión y transmisión.
La tarea de construir un sitio web para reunir toda la información de DevFest LATAM estuvo a cargo del equipo de Web & Apps, integrado por organizadores entusiastas de Flutter.
El equipo asumió con éxito el reto de crear el sitio web oficial y las apps - disponibles para Android y iOS -, utilizando un mismo código.
EPÍGRAFE: Múltiples plataformas, el mismo código El sitio web y la app de DevFest LATAM fueron desarrolladas en Flutter
El contenido fue la estrella
Hacer un evento memorable con contenidos de calidad no fue una tarea sencilla. Organizamos un Call for Papers accesible al público en general, expertos de la industria y Google Developer Experts. Durante el proceso evaluamos las propuestas con imparcialidad, lo cual permitió garantizar su calidad. Realizamos rondas de evaluación, entrevistas y ofrecimos apoyo a los speakers.
Tal fue la expectativa generada, que recibimos propuestas de otros países y regiones, como Estados Unidos, Brasil y España. Con una mayor diversidad de idiomas, incluimos contenidos en español, inglés y portugués.
Luz, cámara, YouTube
Inicialmente, gracias a una experiencia de uso positiva en la transmisión de otros eventos de la comunidad, optamos por utilizar StreamYard.
Sin embargo, el canal de YouTube de Google Developers LATAM nos abrió sus puertas, brindó el soporte técnico necesario y la oportunidad de generar un mayor impacto regional con la transmisión del DevFest LATAM, lo cual nos motivó a maximizar los esfuerzos.
La experiencia DevFest más allá de lo virtual
El DevFest es un gran evento para disfrutar de buenas presentaciones, conocer e interactuar con otros miembros de la comunidad y participar en dinámicas divertidas. Pero, ¿cómo trasladar esta experiencia a un entorno virtual?
Decidimos que Discord era el mejor canal para expandir la experiencia de los asistentes: alentarlos a participar activamente, facilitar la interacción con los speakers después de cada presentación, realizar networking y asistir al after-party por cada día de evento.
Agradecimientos
Queremos agradecer a todos los integrantes del Equipo organizador del DevFest LATAM y a cada una de las comunidades de los distintos países que apoyaron en la difusión de este evento.
DevFest LATAM en números
3 días de evento
28 comunidades, 11 países diferentes de LATAM
2K asistentes registrados orgánicamente
10.8K de usuarios únicos durante los tres días de transmisión
14.7K Total Views
+36 ponentes
+ 32 hs. de transmisión en vivo
3 sesiones con transmisión simultánea
Contenidos en 3 idiomas (Español, Inglés y Portugués)
