DEV Community

Giovani Fouz
Giovani Fouz

Posted on

Más allá de @JavascriptInterface: Diseñando un ORM SQLite Reactivo Nativo para Android WebViews

#android #database #java #javascript

:

Más allá de @JavascriptInterface: Diseñando un ORM SQLite Reactivo Nativo para Android WebViews

El Problema que Todos Ignoran

Si alguna vez has construido una aplicación híbrida para Android combinando Java/Kotlin con un WebView, conoces el dolor de las complejidades en la comunicación entre ambos mundos.

El flujo de trabajo habitual es frustrante:

  1. Definir un modelo en Java.
  2. Escribir consultas SQL a mano.
  3. Mapear manualmente todo a JSON usando bibliotecas como Gson o Moshi.
  4. Exponer métodos a través de @JavascriptInterface.
  5. Repetir el proceso para cada modelo.

Para una aplicación mediana, esto puede resultar en miles de líneas de código "intermedio" que son frágiles, difíciles de depurar e imposibles de escalar.

Por Qué Las Soluciones Existentes No Son Suficientes

El ecosistema de Android es impresionante, pero está fragmentado para este caso específico:

Herramienta Lo que falta
Room Excelente para nativo, pero no se comunica directamente con WebView.
Gson/Moshi Solo soluciona la serialización, no la arquitectura del puente.
SQLite Crudo Muy verboso, propenso a errores y sin seguridad de tipos a través del puente.

Me di cuenta de que no necesitábamos otro puente genérico; necesitábamos un ORM Reactivo Nativo diseñado específicamente para unir SQLite de Android y el runtime de JavaScript.

La Visión: Una API Unificada

Imagina interactuar con tu base de datos local desde JavaScript con la misma facilidad que lo haces en código nativo.

Java (Configuración):

ReactiveSQLite db = ReactiveSQLite.with(context)
    .register(Product.class)
    .connectTo(myWebView)
    .build();
Enter fullscreen mode Exit fullscreen mode

JavaScript (Consultas):

// Una consulta reactiva en tiempo real directamente desde el WebView
const products = await ReactiveSQLite.query('Product')
    .where('price').gt(500)
    .live()
    .subscribe(data => {
        renderUI(data); // Actualizaciones automáticas al cambiar la DB
    });
Enter fullscreen mode Exit fullscreen mode

Detrás de Escena

Quería evitar dependencias pesadas y sobrecargas. Esta arquitectura se basa en:

  • Cero Dependencias: Solo el SDK de Android.
  • Inyección Inteligente: Un BridgeRuntimeInjector personalizado que maneja la capa de comunicación sin boilerplate complejo.
  • Administrador de Consultas en Vivo: Un bus de eventos nativo a JS que envía actualizaciones al WebView solo cuando los datos subyacentes cambian.
  • Patrón Decorador: Funciona bien con otras bibliotecas de puente (como WebVirt), eliminando la necesidad de refactorizar toda tu aplicación para integrarlo.

¿Por Qué Estoy Escribiendo Sobre Esto?

He construido un panel totalmente funcional para probar cada caso extremo y el rendimiento es significativamente mejor que hacer polling a la base de datos o serializar grandes trozos de JSON en cada interacción de UI.

¡Pronto abriré el código de este proyecto!

En los próximos posts, profundizaré en:

  1. La Arquitectura: Cómo construí el JsonEngine y ModelRegistry sin usar reflexión pesada o bibliotecas de terceros.
  2. El Motor de Reactividad: Cómo enviar cambios desde Java a JS sin WebSockets.
  3. El Roadmap: Por qué el siguiente paso es la generación automática de tipos de TypeScript a partir de anotaciones de Java.

Si te enfrentas a la comunicación entre WebView y nativo o estás interesado en arquitectura de Android, presiona el botón de **Seguir. Compartiré el desglose técnico y la liberación del código en las próximas semanas.

Top comments (0)