From f75fbf7c4a856987345abcd8e0426c7fbeea9cdb Mon Sep 17 00:00:00 2001 From: hacklab Date: Tue, 20 Oct 2026 13:11:40 +0200 Subject: [PATCH] guia: la estrategia de capa encima, sus reglas y donde va cada cosa Seccion nueva al principio: por que capa encima y no fork, app propia ni reescribir respuestas; siete reglas; tabla de que va en cada fichero y los pasos para seguir modificando. En version nueva del dev, repasar la APK con REA. Cifras de lo que cambiamos del dev rehechas contra la APK 1.3.3 (15 ficheros, 516 lineas). --- GUIA_DE_DESARROLLO.md | 75 +++++++++++++++++++++++++++++++++++---- docs/FRONTERA_UPSTREAM.md | 4 +-- docs/guia_pdf/guia.html | 3 +- 3 files changed, 72 insertions(+), 10 deletions(-) diff --git a/GUIA_DE_DESARROLLO.md b/GUIA_DE_DESARROLLO.md index c1af603..67a23e7 100644 --- a/GUIA_DE_DESARROLLO.md +++ b/GUIA_DE_DESARROLLO.md @@ -12,6 +12,63 @@ cambiamos cómo se ve y se usa en el móvil, y lo hacemos en ficheros nuestros. Los números y de dónde salen están en `docs/FRONTERA_UPSTREAM.md`. +## La estrategia: una capa encima + +Lo del dev entra tal cual y lo nuestro va encima, en ficheros nuestros: hojas de +estilo, vistas y un router propio que va delante del suyo. Se eligió así frente a +las otras salidas: + +- Un fork que copie sus vistas y siga por libre se queda viejo en semanas (39 + versiones en siete semanas). +- Una app propia que hable con su backend obliga a rehacer toda la interfaz, y Oasis + no tiene API: devuelve HTML. +- Reescribir su HTML o sus respuestas al vuelo se rompe sin avisar con cualquier + cambio suyo. Se probó y se quitó el 20/10/2026. + +Las reglas de la capa: + +1. Lo del dev no se cambia: ni su código ni lo que contesta (HTML, redirecciones, + cabeceras). Nuestro código no mira sus respuestas. +2. El aspecto, con CSS en nuestras hojas. +3. Otro HTML en una pantalla suya: función en `mobile_ui.js` y una línea en su vista. +4. Una pantalla o una ruta nueva: en `fork_routes.js`; lo que no es nuestro pasa al + dev con `next()`. +5. Si una pantalla del dev ya hace algo (editar el perfil, escribir, guardar los + módulos), se enlaza a ella o se envía a su ruta y se acepta a dónde vuelve. No se + copia su lógica. +6. Se pueden usar sus funciones (`getConfig`, `saveConfig`, leer de sus modelos). + Reescribirlas, no. +7. Si algo no se puede hacer con estas reglas, se le pide al dev. + +Dónde va cada cosa: + +| Quiero... | Va en | +|---|---| +| Cambiar colores, tamaños, márgenes | `styles/mobile_ux.css` (los dos skins) o `hive_acampada.css` (solo Acampada) | +| Cambiar la paleta de Acampada | Variables `--a26-*` de `themes/Acampada.css`; las elegibles, en `mobile_settings.js` | +| Otro HTML en una pantalla del dev | Función en `views/mobile_ui.js` + una línea en su vista | +| Una pantalla nueva | Vista propia en `views/mobile_*.js` + ruta en `fork_routes.js` | +| Algo en Ajustes del móvil | `views/mobile_settings.js` | +| Un texto nuevo | `translations/i18n_fork.js`, en los 11 idiomas | +| Un icono | `views/mobile_icons.js` | +| Un workflow | `models/fork_workflows.js` | +| Algo de la APK | `android/scripts/sobre_oficial.sh` o `android/icono/` | +| Algo que la capa no deja | Pedírselo al dev | + +Cómo seguir modificando, paso a paso: + +1. Arrancar en local (ver «Probar en local») y localizar en el inspector la clase o + la pantalla. +2. Decidir con la tabla dónde va. Si la respuesta es un fichero del dev, parar y + releer las reglas. +3. Hacer el cambio. +4. Pasar «Antes de hacer commit». +5. Commit en castellano y subir la rama `PRUEBAS` a forgejo. +6. Montar la APK con `android/scripts/sobre_oficial.sh` y probarla en el emulador + `Oasis_Pruebas`. +7. Si entra un fichero o un mecanismo nuevo, apuntarlo en esta guía en el mismo commit. + + ## Lo que no se toca - `src/backend/backend.js`. Cambia en 34 de cada 39 versiones. Ni rutas nuevas, ni @@ -140,9 +197,11 @@ router pasa al del dev con `next()`: }) ``` -Retocar lo que contesta el dev. También en `fork_routes.js`, en `wrapUpstream`: deja -que el dev conteste y luego mira la respuesta. Así sabemos a qué sección apagada se -quería entrar (el dev solo manda a `/modules`) o añadimos `?saved=1` al guardar. +Retocar lo que contesta el dev: no se hace (regla 1). Antes había un `wrapUpstream` +que miraba sus redirecciones para el aviso de sección apagada, `?saved=1` al guardar +módulos y la vuelta a Ajustes tras guardar el perfil; se quitó el 20/10/2026 porque +cualquier cambio suyo lo rompía sin avisar. Ahora Ajustes enlaza a `/profile/edit` y +`/feed/create`, y guardar los módulos vuelve a donde decide el dev. Textos. En `i18n_fork.js` y en los 11 idiomas (en, es, fr, eu, de, it, pt, zh, ar, hi, ru). Antes, mirad que la clave no exista ya en `oasis_en.js`, porque si existe la @@ -187,6 +246,10 @@ nombre es el de la ruta: `/tribes` es `tribes`. 4. Se repasan a 412 px las pantallas de la lista de arriba. 5. Se monta la APK sobre la oficial de esa misma versión: `OASIS_VERSION=x.y.z android/scripts/sobre_oficial.sh`. +6. Con REA se mira otra vez cómo extrae y cómo usa la WebView su APK + (`copyNodeProjectIfNeeded`, `configureWebView` y el manifiesto). Si cambia, + `sobre_oficial.sh` puede tener que cambiar. Los comandos, en + `docs/ARQUITECTURA_APK.md`. ## Probar en local @@ -228,14 +291,14 @@ Cómo está hecha la APK del dev por dentro (sacado con REA): `docs/ARQUITECTURA Para el móvil, la referencia es el `nodejs-project` de la APK oficial del dev, no su git: él mete cambios de móvil (en `backend.js`, `SSB_server.js`, `phone_module.js`...) -que solo están en la APK. Comparado con eso, la rama cambia 17 ficheros suyos, 561 -líneas (19/10/2026). Por tamaño: +que solo están en la APK. Comparado con eso, la rama cambia 15 ficheros suyos, 516 +líneas (20/10/2026, contra el `nodejs-project` de la APK 1.3.3). Por tamaño: - `backend/blobHandler.js` (190): limpiar los metadatos de las fotos también en Android. Es una función nuestra metida en su fichero; habría que proponérsela al dev. - `configs/oasis-config.json` (87) y `configs/config-manager.js` (18): la config de serie del móvil (tema Acampada, workflow acampada, barra de abajo). -- `views/main_views.js` (62), `settings_view.js` (34), `welcome_view.js` (11), +- `views/main_views.js` (64), `settings_view.js` (33), `welcome_view.js` (20), `tribes_view.js` (9), `vote_view.js` (7): enganches a `mobile_ui.js` y el orden de carga de las hojas. Es lo que la guía permite, pero hay que revisarlo en cada versión. - `main.js` (45): DNS del sistema primero, para respetar la VPN. diff --git a/docs/FRONTERA_UPSTREAM.md b/docs/FRONTERA_UPSTREAM.md index e8bde8a..21835ed 100644 --- a/docs/FRONTERA_UPSTREAM.md +++ b/docs/FRONTERA_UPSTREAM.md @@ -156,8 +156,8 @@ nada, pero son peso muerto y confunden. | Antes (en ficheros del dev) | Ahora | |---|---| -| `backend.js`: `checkMod` envuelto para recordar la seccion apagada | El router propio mira las redirecciones a `/modules` de vuelta | -| `backend.js`: ruta `POST /modules/enable` y `?saved=1` tras guardar | Router propio | +| `backend.js`: `checkMod` envuelto para recordar la seccion apagada | Quitado el 20/10: no se miran las respuestas del dev | +| `backend.js`: ruta `POST /modules/enable` y `?saved=1` tras guardar | Quitado el 20/10: se guarda con la ruta del dev y vuelve a donde dice el | | `modules_view.js`: vista de Modulos del movil | `views/mobile_modules_view.js`, servida por el router propio | | `workflows_model.js`: cuatro modulos mas en `activists` | Workflow propio `acampada` registrado desde `models/fork_workflows.js` | | `vote_view.js`, `tribes_view.js`, `settings_view.js`, `main_views.js`, `welcome_view.js`: funciones nuevas | Funciones en `views/mobile_ui.js`; en la vista de upstream queda la llamada | diff --git a/docs/guia_pdf/guia.html b/docs/guia_pdf/guia.html index 55db2fc..bfbce40 100644 --- a/docs/guia_pdf/guia.html +++ b/docs/guia_pdf/guia.html @@ -228,8 +228,7 @@ table.tight td { padding: 1.1mm 2mm; } - - wrapUpstream mira tu respuesta (redirecciones) sin cambiarla + Lo que contestan tus rutas no se mira ni se cambia Nuestro router va justo delante del tuyo: una sola línea en backend.js lo monta.