MultiView Hub — Documento técnico de plataforma

Un centro de monitoreo que trata cada fuente por lo que sabe hacer

Cómo se resuelve mostrar a la vez plataformas de vídeo, cámaras IP y paneles web, cuando cada una acepta una URL distinta, se incrusta distinto y permite controlar cosas distintas. La respuesta no es un caso especial por plataforma: es un contrato que cada fuente declara.

Plataforma · escritorio · Electron Persistencia · SQLite local Fuentes · 7 adaptadores Pruebas · 111 · 13 suites
01

El problema

Un puesto de monitoreo necesita ver varias cosas a la vez: transmisiones, cámaras y paneles. El obstáculo no es la cuadrícula, sino que cada origen se comporta distinto.

DiferenciaEjemplo
La URL que pega el usuario no es la que se puede incrustarEl enlace que se comparte y el de reproducción embebida son distintos
Cada plataforma tiene su propia forma de reconocerseDominios, subdominios y variantes cortas
No todas permiten lo mismo una vez cargadasAlgunas dejan controlar volumen real; otras solo silenciar
Algunas no son web en absolutoUna cámara IP habla un protocolo que el navegador no entiende

La salida fácil es una cadena de condicionales por plataforma dentro de la vista. Funciona hasta la cuarta fuente, y a partir de ahí cada añadido toca código que ya funcionaba.

02

El contrato de fuente

Cada plataforma implementa el mismo contrato mínimo. Son dos funciones y una declaración.

Adaptador de fuente
type qué clase de fuente es capabilities qué permite hacer una vez cargada · volumen real · control de reproducción detect(url) ¿esta URL es mía? normalize(url) → URL incrustable, o lanza si no es válida
Todo lo específico de una plataforma vive dentro de su adaptador. La vista no sabe qué plataforma está mostrando: sabe que tiene una URL incrustable y una lista de lo que puede controlar.

Añadir una fuente nueva es escribir un archivo que cumpla el contrato y registrarlo. No se toca la cuadrícula, ni la persistencia, ni las demás fuentes.

03

Resolución y comodín

Al añadir una URL, el gestor recorre los adaptadores en orden: los específicos primero y el genérico al final.

Orden de resolución
plataformas específicas → cámara → web (comodín) si ninguno reconoce la URL → error explícito con la URL original
El comodín va al final por necesidad: reconoce cualquier cosa que sea una página, así que puesto antes se quedaría con las URLs de las plataformas específicas y perdería su tratamiento particular.
Un fallo que dice qué falló

Cuando ningún adaptador reconoce la URL, el error la incluye. Parece menor, pero en una aplicación donde el usuario pega enlaces de fuentes muy distintas, un «no se pudo cargar» sin decir cuál obliga a probar de a una para encontrar la que sobra.

04

Capacidades declaradas

Esta es la parte del diseño que evita la peor clase de error de interfaz: un control que existe y no hace nada.

Tipo de fuenteVolumen realControl de reproducción
Plataformas de vídeo con API de reproductor
Plataformas con incrustación restringidanono
Cámara IPnono
Declararlo es más honesto que intentarlo

La alternativa habitual es ofrecer el control en todas partes y confiar en que la plataforma lo acepte. Cuando no lo acepta, el deslizador se mueve y el volumen no cambia — y el usuario concluye que la aplicación está rota, no que la plataforma no lo permite.

Al declarar la capacidad, la interfaz puede no mostrar el control donde no funciona. Es menos funcionalidad aparente y más confianza real.

05

Cámaras IP

Una cámara de seguridad transmite en un protocolo que ningún navegador reproduce de forma nativa. Es la fuente que rompe el supuesto de «todo es una página web».

La cadena
URL de la cámara → adaptador: valida el protocolo y la deja intacta → gestor de transmisión: transcodifica a un formato web → vista: carga un reproductor local
El adaptador no transforma la URL de la cámara. Su trabajo es reconocerla y validarla; la conversión es responsabilidad de otro componente. Mezclar las dos cosas ataría el contrato de fuente —que es puro y se prueba solo— a un proceso de transcodificación.

Esa separación es la que permite que los adaptadores se prueben sin levantar nada: son funciones que reciben una cadena y devuelven otra.

06

Perfiles y persistencia local

La configuración vive en el equipo, en una base de datos local. Tres tablas: perfiles, fuentes y ajustes.

Un perfil es una disposición guardada: qué fuentes, en qué posición de la cuadrícula y con qué ajustes. Cambiar de perfil reconfigura el puesto entero, que es la operación real de un centro de monitoreo — no se añaden fuentes de a una cada mañana.

Sin cuentas ni servidor

No hay registro, ni sincronización, ni datos en un servidor ajeno. Para una herramienta de escritorio que muestra cámaras de seguridad, que la lista de cámaras no salga del equipo no es una limitación: es el comportamiento correcto.

La aplicación incluye además gestión de licencia y de nivel de funcionalidad, control de ventanas flotantes siempre visibles, icono en la bandeja del sistema y grabación.

07

Arquitectura y verificación

Aplicación de escritorio con los tres procesos separados que impone la plataforma, y la lógica concentrada donde puede probarse.

Estructura
src/main/ proceso principal adapters/ los 7 adaptadores + el gestor de resolución db/ esquema y repositorio local camera/ transcodificación de cámaras license/ tier/ settings/ window/ tray/ recording/ src/preload/ puente controlado entre procesos src/renderer/ interfaz src/shared/ tipos y validación compartidos
Los adaptadores, el repositorio y los servicios de ajustes, licencia y nivel viven en el proceso principal y no dependen de la interfaz. Es lo que permite que las 111 pruebas corran sin abrir una ventana.

Dónde están las pruebas

De las trece suites, ocho cubren los adaptadores — una por fuente más el gestor. Es la decisión correcta: los adaptadores son el punto donde entra lo impredecible, que es una URL escrita por una persona. El resto cubre el repositorio, la validación compartida y los servicios de ajustes, licencia y nivel.

La puerta de calidad corre el chequeo de tipos y las pruebas en cada cambio.