Prefacio: en proyectos híbridos que combinan Native y Flutter es habitual que Android use OkHttp y Flutter use Dio para las peticiones de red. Esta duplicidad genera problemas prácticos como mantener dos implementaciones de mecanismos transversales como reintentos, cache o redirección a login cuando expira un token. Además, herramientas de captura como Charles funcionan fácilmente con el stack nativo mientras que Dio ignora la configuración de proxy del teléfono salvo que se configure en código, lo que complica el trabajo con proxies.
Objetivo: centralizar las peticiones en la capa nativa de la app para que tanto las llamadas existentes como las nuevas se ejecuten en el lado nativo. Flutter solo tendría que parsear la respuesta y mostrar la interfaz. Así se evita duplicar lógica de negocio y se facilita el uso de herramientas de depuración nativas.
Entendiendo Dio: Dio permite personalizar el proceso de envío de peticiones mediante la sustitución de HttpClientAdapter y del Transformer. En el flujo interno de Dio hay tres puntos clave que conviene conocer: Focus 1 obtener el responseBody a través de httpClientAdapter.fetch; Focus 2 construir el objeto Response a partir de responseBody y su stream; Focus 3 usar el transformer para leer el contenido del stream y convertirlo en data que contenga el cuerpo de la respuesta y la estructura de protocolo habitual como code, msg y json. Para redirigir las peticiones al lado nativo hay que sustituir el componente que realiza fetch.
HttpClientAdapter y HttpClient: HttpClientAdapter es el puente entre Dio y la implementación concreta que envía requests. Por defecto Dio usa un IOHttpClientAdapter que crea un HttpClient de Dart IO. Si proporcionamos un HttpClientAdapter personalizado podemos controlar dónde y cómo se envía la petición.
Solución propuesta: crear un NativeClientAdapter que reescriba fetch para enviar los parámetros de la petición al lado nativo mediante un canal de plataforma. El flujo sería: Flutter prepara un NativeRequestOption con baseUrl, path, method, data y queryParameters; NativeClientAdapter invoca el canal nativo enviando ese objeto; la capa nativa usa OkHttp en Android (o la librería equivalente en iOS) para ejecutar la petición y devuelve un objeto sencillo con httpCode y data donde data contiene el cuerpo de la respuesta en formato JSON de la API de negocio; de vuelta en Flutter un NativeTransformer interpreta ese resultado y lo convierte en la estructura que espera Dio.
Detalles prácticos: en Flutter el NativeClientAdapter implementa fetch y en vez de usar un stream real devuelve un ResponseBody adaptado que contiene el httpCode y el cuerpo ya serializado. El NativeTransformer en transformResponse decodifica la cadena JSON devuelta por la capa nativa y la transforma en un Map o en el tipo esperado por la aplicación. En la capa nativa basta con recibir el NativeRequestOption, ejecutar la petición con la librería nativa (por ejemplo OkHttp), construir la respuesta con un campo httpCode y un campo data con el cuerpo de la API y enviarlo al cliente Flutter por el mismo canal.
Ventajas de esta aproximación: evita duplicar lógica de red en Native y Flutter, facilita implementar una única política de reintentos, cache, manejo de expiración de token y redirecciones hacia el login, permite aprovechar herramientas nativas de captura como Charles sin cambios en Flutter y centraliza el manejo de certificados y políticas de seguridad. También facilita el uso de interceptores nativos y librerías avanzadas de networking propias del sistema operativo.
Consideraciones y alternativas: se puede optar por la inyección de un HttpClientAdapter personalizado como se propone o por intercepción de peticiones en un interceptor que reenvíe a la capa nativa. Cada equipo elegirá según requisitos de performance y complejidad. Hay que gestionar correctamente errores, cancelaciones y timeouts en ambos lados y serializar de forma eficiente los cuerpos y encabezados para no degradar la experiencia.
Ejemplo de contrato entre capas: la respuesta nativa puede tener una estructura simple con httpCode y data para el cuerpo de la API. De esta forma el transformer en Flutter decodifica data y la convierte en el objeto que consume la app. Con esta arquitectura se pueden aplicar reglas transversales como forzar redirección a login cuando el código de negocio indique token expirado, sin duplicar código en Native y Flutter.
Sobre Q2BSTUDIO: en Q2BSTUDIO somos una empresa de desarrollo de software y aplicaciones a medida especializada en soluciones móviles y cloud. Ofrecemos servicios de software a medida y desarrollo de aplicaciones y software a medida que incluyen integración nativa y Flutter, así como servicios de inteligencia artificial para empresas. Nuestro equipo combina experiencia en desarrollo móvil, integración de redes, agentes IA y automatización para entregar soluciones escalables y seguras.
Servicios complementarios: además de desarrollar arquitecturas de networking híbridas ofrecemos ciberseguridad y pentesting, servicios cloud aws y azure, servicios inteligencia de negocio y soluciones Power BI para explotación de datos. Palabras clave que definen nuestro foco incluyen aplicaciones a medida, software a medida, inteligencia artificial, ciberseguridad, servicios cloud aws y azure, servicios inteligencia de negocio, ia para empresas, agentes IA y power bi.
Si necesitas centralizar las comunicaciones de Flutter en la capa nativa para simplificar mantenimiento, mejorar seguridad y facilitar la depuración, contacta con Q2BSTUDIO para evaluar la mejor arquitectura y plan de implementación.