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.
A partir de agosto de 2021, Google៕ Play Console les solicitará a todas las apps nuevas lo siguiente:
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.
Este es el resumen de todos los cambios:
TIPO DE LANZAMIENTO
REEMPLAZO
REQUERIDO A PARTIR DE AGO 2021
Nuevas apps de Google Play
APK
Android App Bundle (AAB)
Nivel de API de destino establecido en 29+
Nivel de API de destino establecido en 30+
Archivos de expansión (OBB)
Play Asset Delivery o Play Feature Delivery
REQUERIDO A PARTIR DE NOV 2021
Actualizaciones de apps existentes de Google Play
Sin requisitos de formato de publicación nuevo
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.
minSdkVersion
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.
Este artículo forma parte de una serie sobre los cambios del atributo de cookies SameSite:
SameSite
Schemeful Same-Site modifica la definición de un sitio (web) de solo el dominio registrable al esquema + dominio registrable. Puedes encontrar más información y ejemplos en Información sobre "same-site" y "same-origin".
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.
SameSite=None; Secure
Puedes habilitar estos cambios para realizar la prueba tanto en Chrome como en Firefox.
chrome://flags/#schemeful-same-site
network.cookie.sameSite.schemeful
true
about:config
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.
SameSite=Lax
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.
SameSite=Strict
SameSite=None;Secure
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.
Secure
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.
SameSite=None
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.
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:
Errores de carga de subrecursos:
Hay más información disponible en Sugerencias de pruebas y depuración para Schemeful Same-Site.
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:
cookie_name
http://site.example/
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.
includeSubDomain
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.
Lax
Strict
None
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.
Las conexiones WebSocket aún se considerarán del mismo sitio si están en la misma seguridad que la página.
Mismo sitio:
wss://
https://
ws://
http://
Entre sitios:
Fotografía de Julissa Capdevilla en Unsplash
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.
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
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.
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
Haz el curso “Minimum and Broken Functionality Spam” en Academia de Play
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
Haz el curso “Web Spam” en Academia de Play
Si bien los errores anteriores son los más comunes, asegúrate de estar al tanto de las últimas políticas ingresando al Centro de Políticas para Desarrolladores de Play. Consulta la capacitación de políticas de Academia de Play de Google, incluidos nuestros nuevos cursos sobre spam, y mira nuestros videos sobre PolicyBites de Play para obtener más información acerca de las actualizaciones recientes de políticas.
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.
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.
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:
Respuestas a preguntas comunes sobre la firma de apps de Google 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.
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.
También puedes consultar el artículo:
Cómo configurar tu app para Play Feature Delivery
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).
Si deseas obtener contenido de forma constante, recuerda consultar la lista de reproducción de MAD Skills en YouTube, los artículos en Medium o esta página de destino útil en la que se muestra todo. La siguiente serie comenzará la próxima semana. ¡No te la pierdas!
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.
No siempre hablamos sobre Kotlin, pero cuando lo hacemos, hablamos mucho del tema. Recientemente, se publicaron varios artículos y videos acerca de Kotlin:
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.
Clases de datos: Cómo contener datos con clase
Hablando del Vocabulario de Kotlin, Murat Yener publicó una secuela de su anterior artículo sobre la función de delegados de Kotlin. Esta vez, analiza los delegados proporcionados en la Biblioteca estándar de Kotlin: lazy, observable, vetoable y notNull.
Delegados integrados
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.
¿Debo aprender Kotlin para Android? (y otras preguntas frecuentes)
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.
Menos fallas y más estabilidad con Kotlin
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:
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.
Episodio 151: Carga de imágenes con Coil
Eso fue todo por hoy. Aprende sobre App Bundles, descarga las últimas versiones de AndroidX, lee los últimos artículos sobre Kotlin y escucha el episodio más reciente del podcast de ADB. Te esperamos pronto para ofrecerte más novedades del universo de desarrolladores de Android.
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!).
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:
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.
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.
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.
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.
¿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 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.
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.
Obtén más información sobre Cómo compilar mejores apps con Kotlin y observa cómo se han beneficiado los desarrolladores de Kotlin a través de la lectura de nuestros casos de éxito. Para comenzar con Kotlin, uno de los lenguajes más populares en el mundo, visita nuestra página Primeros pasos.
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)
Revive el evento del año: DevFest LATAM 2020
Agenda: https://devfestlatam.dev/#/agenda
Día 1: https://www.youtube.com/watch?v=3tKJMl-EM8U
Día 2 - Agenda Azul: https://www.youtube.com/watch?v=nGf6oOWohzM
Día 2 - Agenda Roja: https://www.youtube.com/watch?v=A4DfWYQEKag
Día 2 - Agenda Verde: https://www.youtube.com/watch?v=lLNBQ-ggukg
Dia 3 - Agenda Azul: https://www.youtube.com/watch?v=__SlFsbXuAI
Día 3 - Agenda Roja: https://www.youtube.com/watch?v=49_dIKVYDUg
Día 3 - Agenda Verde: https://www.youtube.com/watch?v=WU8o-hy5v80
