Resultados de Google Summer of Code 2025

El programa Google Summer of Code (GSoC) se centra en involucrar a nuevos desarrolladores de todo el mundo con el desarrollo de software de código abierto. Google patrocina a colaboradores para que trabajen con una organización mentora de código abierto en un proyecto de programación de 12 semanas durante el verano. En los últimos 20 años, más de 20,000 colaboradores han participado en Google Summer of Code.

En 2025, Dart participó como organización mentora en Google Summer of Code por sexto año consecutivo. Este año recibimos más de 100 propuestas de proyecto de participantes potenciales de todo el mundo. Hoy, destacamos algunos de los proyectos que mentoreamos este verano. Los colaboradores describen sus proyectos en este post.

By Jing Shao

Un objetivo clave en el desarrollo de aplicaciones móviles es ofrecer una experiencia verdaderamente nativa. Antes de este proyecto, las aplicaciones Flutter en iOS tenían una limitación importante: los desarrolladores no podían añadir acciones personalizadas al menú contextual nativo de iOS. Durante GSoC 2025, implementé con éxito el soporte de menú contextual personalizado para Flutter en iOS, lo que mejoró significativamente las capacidades de interacción de las aplicaciones Flutter en iOS.

Este proyecto creó la nueva IOSSystemContextMenuItemCustom API, permitiendo a los desarrolladores añadir fácilmente acciones personalizadas al menú nativo de iOS a través de la propiedad contextMenuBuilder del TextField; los desarrolladores pueden añadir elementos de menú con títulos y callbacks personalizados. La implementación conecta Flutter con el sistema UIMenu nativo de iOS, asegurando que los elementos personalizados se integren de forma fluida con las opciones estándar del menú de iOS (copiar, pegar) manteniendo el aspecto y comportamiento nativo.

Con esta mejora, los desarrolladores de Flutter ahora pueden construir aplicaciones más expresivas y ricas en funcionalidades. Este trabajo representa un paso importante para Flutter en la entrega de excelentes experiencias nativas multiplataforma, dando a los desarrolladores herramientas potentes para crear aplicaciones destacadas. Para más detalles, consulta mis blogs técnicos y PRs en GitHub. ¡No dudes en contactarme si tienes alguna pregunta! Me gustaría agradecer a mis mentores Justin y Huan por su invaluable guía y apoyo durante todo este proyecto.

A continuación se muestra un ejemplo con elementos de menú personalizados como Clear Text, Add Heart ❤️, y Uppercase junto con elementos estándar del menú de iOS en el menú contextual nativo.

By Gedion Ezra

Antes de este proyecto, los desarrolladores de Dart que querían crear aplicaciones de terminal interactivas a menudo tenían que cambiar a Rust, Go o Python. No existía un framework maduro de interfaz de usuario basada en texto (TUI) en Dart, lo que limitaba a los desarrolladores a interfaces gráficas (GUI) o herramientas CLI estáticas. Como parte de GSoC 2025, construimos Pixel Prompt, un framework de UI para terminales inspirado en el enfoque declarativo y basado en componentes de Flutter. Pixel Prompt permite a los desarrolladores crear aplicaciones interactivas dinámicas completamente en Dart.

Pixel Prompt introduce un modelo de Component a ComponentInstance, inspirado en la arquitectura por capas de Flutter que mapea un widget (en la capa de widgets) a una capa de elementos y, a su vez, a la capa de RenderObject. Los Components describen la UI de forma declarativa mientras que los ComponentInstances gestionan el estado, el layout y el renderizado. Echa un vistazo a una versión simplificada de la arquitectura:

El framework soporta componentes con y sin estado, manejo de entrada y renderizado optimizado con doble buffer y diffing ANSI. Esto mejora el rendimiento al minimizar los redibujados del terminal y permite pruebas golden confiables con un intérprete de terminal virtual.

Para dar una idea visual de lo que Pixel Prompt puede lograr, a continuación se muestran capturas de pantalla de algunas demos. Estas demuestran el layout declarativo, los componentes interactivos y las actualizaciones en tiempo real que soporta el framework, mostrando que Dart ahora puede potenciar aplicaciones de terminal completamente interactivas sin salir de su ecosistema.

Si bien Pixel Prompt ya permite construir aplicaciones de terminal básicas, hay más por venir: el soporte para componentes complejos como TextArea y Tables, un sistema de layout similar a flex, una API de animación dedicada y un depurador visual están planificados para futuras contribuciones. Los desarrolladores interesados pueden explorar los issues abiertos y contribuir en el repositorio de pixel_prompt.

By Amr Ahmed

El objetivo principal de TestGen, un proyecto experimental que automatiza la generación de pruebas unitarias para Dart, es mejorar la cobertura de pruebas generando casos de prueba que específicamente se dirigen a líneas no cubiertas en el código. Al aprovechar los grandes modelos de lenguaje (LLMs) para producir pruebas significativas, TestGen reduce el esfuerzo manual necesario para escribir pruebas, ayudando a los desarrolladores a lograr una mayor cobertura y mejorar la calidad del código.

Uno de los principales desafíos al usar LLMs para la generación automatizada de pruebas es decidir cuánto contexto de código darle al modelo. Por ejemplo, si una función necesita pruebas y proporcionamos el archivo completo como contexto, el LLM puede abrumarse y producir pruebas irrelevantes o inexactas. Si proporcionamos solo la función en sí, el modelo puede pasar por alto dependencias importantes dentro de la función, lo que lleva a pruebas incompletas o rotas. Para solucionar esto, TestGen usa el analyzer de Dart para analizar todo el código en Declarations, que son clases que representan una construcción de código como una función, variable, clase o mixin**.** Después del análisis, construye un grafo de dependencias entre estas declaraciones, que muestra exactamente las piezas de código de las que depende una declaración dada. Esto se hace recorriendo el Abstract Syntax Tree (AST) de una declaración dada y registrando sus dependencias durante la visita. Usando este grafo, TestGen puede proporcionar al LLM solo el ****contexto relevante (context-aware prompting) a una profundidad configurable, ayudándole a generar pruebas precisas y enfocadas sin ruido adicional.

Para que la generación de pruebas sea efectiva, TestGen se integra con package:coverage para detectar automáticamente qué partes del código aún no están probadas y enfocarse en ellas. La herramienta se conecta a modelos de Gemini a través de package:google_generative_ai, usando variantes como gemini-2.5-pro, gemini-2.5-flash y gemini-2.5-flash-lite para generar casos de prueba. Estas pruebas luego pasan por un bucle de validación y retroalimentación, donde se ejecutan y se verifican errores. Si se encuentran problemas, los errores se devuelven al LLM para que pueda refinar la salida, haciendo que las pruebas finales sean más precisas y confiables.

Hay más por venir para este paquete, incluyendo nuevas funcionalidades, pruebas mejoradas y soporte para proyectos Flutter. Puedes consultar la lista actual de issues en el repositorio de dart_testgen. Para un ejemplo de cómo se ven los prompts generados, consulta el ejemplo de default-prompt. Más detalles sobre el proyecto están disponibles en el informe completo de GSoC.

By Marshelino Maged

Las bibliotecas y utilidades de Android típicamente se documentan con fragmentos de código Java/Kotlin. Si bien JNIgen permite generar bindings de Dart para estas bibliotecas, escribir código Dart contra los bindings puede ser un desafío debido a las diferencias sintácticas y estructurales entre los lenguajes. Esto significa que los desarrolladores no pueden reutilizar directamente los muchos ejemplos de Java/Kotlin que se encuentran en la documentación oficial de Android y tutoriales. El proyecto native_doc_dartifier fue creado para abordar esta brecha traduciendo automáticamente los fragmentos de Java y Kotlin en la documentación de Android a sus equivalentes en Dart.

El proyecto se basa en JNIgen, que genera bindings de Dart para APIs de Java y Kotlin a través de la interfaz de funciones externas (FFI). Dado que Java y Dart difieren tanto en sintaxis como en semántica, una traducción directa no es suficiente. Por ejemplo, Java soporta la sobrecarga de métodos mientras que Dart no, lo que lleva a JNIgen a desambiguar los bindings con métodos renombrados como add$1 y add$2. Para generar código Dart preciso, el modelo de traducción debe tener en cuenta estas convenciones de binding en lugar de depender de una conversión superficial.

Un gran desafío técnico fue la escala: los bindings para bibliotecas de Android a menudo incluyen cientos de miles de líneas de código boilerplate, superando con creces los límites de entrada incluso de los modelos de lenguaje más grandes (actualmente 1M de tokens). Para abordar esto, el proyecto introdujo la extracción de Abstract Syntax Tree (AST), que reduce los bindings a su superficie de API pública — resultando en aproximadamente el 6% del tamaño original — preservando la información crítica. Esto se combinó con generación aumentada por recuperación (RAG), donde el AST de cada clase se almacena por separado y solo las clases más relevantes se recuperan según el fragmento que se está traduciendo.

Al combinar la extracción de AST con selección de contexto basada en recuperación, native_doc_dartifier es capaz de producir traducciones de Dart que son precisas y consistentes con los bindings generados, manteniéndose eficientes dentro de las restricciones de contexto del LLM. El resultado es una solución práctica que reduce la fricción para los desarrolladores de Dart que trabajan con documentación de Android y fortalece la interoperabilidad entre los ecosistemas de Java/Kotlin y Flutter.

Dado que las traducciones son generadas por un LLM, pueden ocurrir errores ocasionales al compilar el código Dart producido. Para mejorar la confiabilidad, el sistema incorpora un bucle de retroalimentación: los errores de compilación se devuelven al LLM durante varias iteraciones, permitiéndole refinar y corregir la traducción hasta que se produce una versión funcional. Este enfoque iterativo aumenta aún más la robustez de los ejemplos generados.

Para más información, visita el repositorio de native_doc_dartifier.

By Nikechukwu Okoronkwo

Dart proporciona una potente interoperabilidad con JavaScript a través de dart:js_interop, que puede usarse para interactuar con código escrito en JavaScript. Sin embargo, escribir bindings para bibliotecas y paquetes grandes puede ser lento y propenso a errores. Para solucionar esto, creamos el JS Interop Generator. Este genera automáticamente wrappers de Dart a partir de un archivo de declaración de TypeScript (.d.ts). Esto ayuda con la adopción de Dart en la web y permite a los desarrolladores de Dart y Flutter aprovechar más fácilmente el vasto ecosistema de bibliotecas JS de NPM y otros lugares.

El generador funciona analizando un archivo .d.ts y transformando sus declaraciones de TypeScript a sus equivalentes en Dart. Las declaraciones se generan basándose en cómo Dart interactúa con JS, asegurando la corrección en términos de implementación de interop con el código JS representado por el código de declaración TS, así como la cercanía a la representación del código en la declaración TS, cuando sea posible.

Soporta una amplia gama de funcionalidades de TS, incluyendo variables, funciones, enums, clases, interfaces, namespaces y type-aliases. El generador produce representaciones equivalentes en Dart de los tipos de TS y aprovecha los tipos existentes de dart:js_interop y package:web cuando es posible. Esto incluye soporte para funcionalidades avanzadas de TypeScript como objetos anónimos, closures anónimos, unions, tipos fusionados y typeof / keyof.

Puedes ver muchos ejemplos en el conjunto de pruebas de integración. Ya hemos usado el generador para crear con éxito bindings para paquetes populares como nanoid y uuid. Para más detalles sobre esto, consulta los resultados de las pruebas del generador.

El proyecto está disponible en el paquete web_generator del repositorio web. Puedes probarlo ejecutando el script bin/gen_interop_bindings.dart. Si encuentras algún problema o bug, no dudes en abrir un issue y/o contribuir!