Resultados de Google Summer of Code 2024

El programa Google Summer of Code (GSoC) se enfoca en integrar a nuevos desarrolladores de todo el mundo con el desarrollo de software de código abierto. Google patrocina a colaboradores para trabajar con una organización mentora de código abierto en un proyecto de programación de 12 semanas durante el verano. Durante los últimos 19 años, más de 20.000 colaboradores han participado en Google Summer of Code.

En 2024, Dart participó como organización mentora en Google Summer of Code por quinto año consecutivo. Este año recibimos 50 propuestas de proyectos 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 Anikate De

Los clientes HTTP existentes de Dart no podían interactuar con APIs nativas de Android, limitando el soporte para KeyStore PrivateKeys, System Proxy, y Certificados instalados por el usuario (todas funciones muy solicitadas por los usuarios de Dart).

El proyecto de código abierto OkHttp, una opción popular para aplicaciones con uso intensivo de red en Android, posee APIs que pueden implementar sin problemas las funcionalidades anteriores. Por lo tanto, OkHttp fue elegido como punto de partida para este proyecto. Usando el proyecto de GSoC 2022, package:jnigen, se generaron bindings JNI para Dart para varias APIs de OkHttp. El OkHttpClient es totalmente conforme con los clientes HTTP existentes, permitiendo una transición sin problemas al uso de OkHttpClient desde cualquier alternativa.

Además de las solicitudes HTTP asíncronas, package:ok_http también soporta WebSockets, lo que requiere pasar todas las pruebas en package:web_socket_conformance_test. Esto permite una transición fluida desde cualquier alternativa de WebSocket. Las aplicaciones Flutter que usan el benchmark de package:ok_http reportan el tamaño de APK más pequeño de entre todos los demás clientes HTTP que Dart ofrece.

Aprovechar los beneficios del OkHttpClient en tus proyectos de Flutter es tan simple como importarlo y editar tu objeto Client actual.

Lee más sobre los detalles del proyecto en el reporte del colaborador de GSoC.

By Mohammad Eid

Dart puede (indirectamente) comunicarse con código Swift. Esto se hace "a través de" ObjC, ya que Dart puede comunicarse con lenguajes basados en C (como ObjC) usando el paquete ffi. Las APIs de Swift pueden anotarse con @objcpara solicitar que el compilador genere cabeceras ObjC para ellas. La generación de los bindings de ffi para Dart se hace automáticamente con ffigen. Para Swift, tendrás que anotar manualmente las APIs con las que quieres comunicarte.

Anotar las APIs de Swift puede ser más complejo que simplemente añadir una anotación @objc. ¿Qué pasa si no eres dueño del módulo? Si no puedes editarlo, debes hacer un wrapper personalizado que refleje las APIs para que puedas anotar los métodos. Además, dado que Swift es un lenguaje moderno y ObjC no, probablemente encontrarás APIs que no son representables en ObjC directamente, así que también tendrás que trabajar alrededor de estos casos.

Swift2ObjC maneja estas cosas por ti: Genera wrappers para módulos de Swift y los anota con @objc, asegurando que todas las APIs sean representables en ObjC — el módulo de Swift no compilará, de lo contrario. Explico los detalles de implementación en este artículo en Medium (que puedes consultar si estás considerando contribuir a la herramienta, ya que sigue en desarrollo activo). También puedes revisar el código fuente en el repositorio swift2obj en GitHub.

By Takuma Ichikawa

Dart permite incrustar muestras de código dentro de comentarios de documentación. Esta es una práctica beneficiosa, porque también se publica como documentación del API y muestra cómo usar el paquete de una manera fácil de entender tanto para los usuarios del paquete como para los desarrolladores. Sin embargo, las muestras de código en los comentarios de documentación no se analizan ni se prueban, lo que dificulta encontrar errores y las hace menos mantenibles. A medida que los proyectos y la documentación crecen, este problema se vuelve más significativo.

Por lo tanto, para GSoC, he desarrollado el paquete dartdoc_test para resolver tales problemas. La herramienta dartdoc_test puede extraer y analizar muestras de código en comentarios de documentación para encontrar errores potenciales. Al añadir el paquete a tu proyecto y ejecutarlo desde la línea de comandos, puedes encontrar errores en todas las muestras de código. También puedes realizar análisis estático de las muestras de código al ejecutar el comando dart test, añadiendo el archivo de prueba de dartdoc_test.

Es fácil probar dartdoc_test en tu proyecto Dart ejecutando los siguientes dos comandos.

dart pub add dev:dartdoc_test
dart run dartdoc_test

Para más información, revisa dartdoc_test en pub.dev.

By TheComputerM

Dart, como un lenguaje que puede compilarse a varios objetivos, incluye capacidades que facilitan la comunicación con binarios nativos. Puedes usar paquetes como dart:ffi para interactuar con APIs de C y package:jni para interactuar con código Java. Solo necesitas escribir algo de código glue para especificar la firma del tipo de la función nativa que estás llamando.

El problema surge cuando usas una librería que tiene muchos exports, demasiados para escribir a mano. Este problema se resuelve con ffigen (un proyecto anterior de GSoC), una herramienta que genera los bindings usando solo los archivos de cabecera de la librería. Para hacer eso tendrías que instalar ffigen, configurar todas las dependencias y requisitos adecuados, luego (probablemente) iterar una y otra vez. Esto no es exactamente la definición de fluido y fácil. Así nació FFIgenPad.

Otro objetivo del proyecto era probar el compilador dart2wasm (puedes encontrar mis experimentos en este blog post). Claro, podríamos haber ejecutado ffigen en un servidor y ponerle una UI. En cambio, me aseguré de que FFIgenPad se ejecute completamente en el navegador compilando tanto libclang como ffigen a WebAssembly (¿por qué usar un servidor para computación cuando puedes usar el sistema del cliente?).

Revisa la demo en https://ffigenpad.surge.sh/ y el código fuente en mi fork en GitHub. Me gustaría agradecer a mis mentores Prerak Mann, Daco Harkes, y Jackson Gardner por estar siempre disponibles cuando pedí ayuda.