Ideación inicial

Batch Cook surge de un problema real: planificar la comida semanal sin perder la cabeza con el stock de la nevera, los tiempos de cocción y la lista de compra. La idea en PR1 era un gestor de batch cooking con secciones bien separadas (Recetario, Nevera, Semana, Batch, Lista, Timers). En PR2 el objetivo era completarla: que la búsqueda de recetas fuera real, no simulada, conectando con una API externa de verdad.

Consultas y pasos con la documentación de Capacitor

Seguí la Migration Guide oficial de Capacitor 8: actualizar los paquetes en package.json, ajustar variables.gradle (minSdk, compileSdk, targetSdk), y revisar la lista de breaking changes por plugin. La parte más costosa fue entender la cadena AGP → Gradle → JDK: el error de minSdk me llevó al de compileSdk, que me llevó a AGP 8.9.1, que requería Gradle 8.11.1, que requería JDK 21. Leyendo los release notes de Android Gradle Plugin esa cadena queda clara.

Pruebas con funcionalidades nativas

• Camera (@capacitor/camera): foto de perfil de receta desde cámara o galería. Requirió minSdk 24.
• Preferences (@capacitor/preferences): persistencia de todo el estado de la app (recetas, nevera, semana, timers). La funcionalidad central del proyecto.
• Haptics (@capacitor/haptics): feedback táctil al marcar un ingrediente de la lista o al activar un timer.
• Local Notifications (@capacitor/local-notifications): notificación cuando un timer llega a cero.
• Filesystem (@capacitor/filesystem): explorado pero finalmente no usado en producción; el estado completo cabe en Preferences.

Decisiones tomadas y aprendizajes

La decisión más importante fue migrar a v8 aunque costara tiempo. Quedarme en v6 habría solucionado el problema a corto plazo pero habría ignorado el feedback directo de la profesora y dejado el proyecto con deuda técnica. Aprendí a leer la cadena de dependencias de Gradle de forma metódica en lugar de ir probando versiones a ciegas. También aprendí que noLoop() con la Page Visibility API es una mejora de rendimiento que cuesta 5 líneas y tiene impacto real en batería.

Bocetos, capturas e iteraciones

Justificación, problemas y conclusiones

Los tres problemas más relevantes de PR2: OneDrive bloqueaba npm install (solución: mover el proyecto fuera de la carpeta sincronizada), la cascada de incompatibilidades de Capacitor v8 (solución: leer los release notes y actualizar AGP, Gradle y JDK en orden), y Android Studio demasiado antiguo (solución: actualizar a Ladybug). Conclusión: PR2 ha sido más de infraestructura que de producto. La app mejora en rendimiento, compatibilidad y funcionalidad real de API, pero el trabajo visible es menor que el trabajo técnico que hay detrás.

Fuentes

• Capacitor 8 docs y Migration Guide — capacitorjs.com
• Android Gradle Plugin release notes — developer.android.com
• TheMealDB API — themealdb.com/api.php
• p5.js Reference (noLoop/loop) — p5js.org/reference
• MDN Web Docs: Page Visibility API — developer.mozilla.org
• Google Fonts, Iconify
• Materiales del aula UOC PR2
• Claude (Anthropic) — asistente de programación para debugging y resolución de problemas técnicos

Vídeo elevator pitch 

Como publicar en Google Play

Para publicar en Google Play necesitas:

1. Cuenta de desarrollador — Google Play Console, pago único de 25$.
2. APK/AAB firmado — en Android Studio: Build → Generate Signed Bundle/APK → Android App Bundle. Necesitas un keystore (créalo desde el mismo wizard).
3. Play Console — crea una nueva app, completa la ficha (nombre, descripción, capturas de pantalla, política de privacidad obligatoria), sube el AAB a «Internal testing».
4. Revisión — Google revisa en 1–3 días. Para apps de estudiante/prototipo, «Internal testing» es suficiente: puedes compartir un enlace con hasta 100 testers sin pasar por revisión pública.

La política de privacidad es el requisito que más gente ignora y que bloquea la publicación. Con una app que usa cámara o almacenamiento local es obligatoria.

Muy buenas noches a tod@s,

Os presento mi propuesta, se trata de una aplicación que gestiona el proceso de Batch Cooking (preparar comidas para toda una semana en una tarde). Os cuento un poco la historia:

La idea surgió a partir de un proyecto que empecé con una amiga, se que es un tema que tiene mucha utilidad y la verdad es que crear una aplicación móvil me parece una integración muy útil. Asi pues también estuve mirando las aplicaciones que ya existían en la Play Store y ninguna tenia todas las funcionalidades que buscaba.

Primeros bocetos de la idea:

Documentación de gran ayuda sobretodo el uso de integraciónes y plugins ya existentes:

• Capacitor Core — https://capacitorjs.com/docs
• @capacitor/haptics — https://capacitorjs.com/docs/apis/haptics
• @capacitor/camera — https://capacitorjs.com/docs/apis/camera
• @capacitor/motion — https://capacitorjs.com/docs/apis/motion

El github del proyecto es el siguiente lo podeis descargar y probar, unicamente necesitais los comandos de npm install y npm run dev para tener el proyecto listo.

Link github: https://github.com/Ramonet02/PR1_Batch_Cooking.git

Índice

1. Introducción y objetivo
2. Decisiones técnicas librería de reconocimiento
3. Arquitectura y estructura del código
4. Decisiones estéticas
5. Flujo de desarrollo

1.     Introducción y objetivo

En esta práctica, se ha desarrollado una aplicación de escritorio interactiva con el objetivo de fomentar buenos hábitos de salud dental en niños. La idea principal es la siguiente: el usuario debe mantener la boca abierta el máximo tiempo posible, simulando el gesto de tener la boca abierta mientras un dentista o mientras se realizan ejercicios de limpieza dental.

La aplicación se ha construido con p5.js para la parte visual y de partículas, MediaPipe FaceLandmarker para la detección facial en tiempo real, y Electron para empaquetar todo como una aplicación de escritorio.

2.     Decisiones técnicas

Dentro de las diferentes opciones se planteó utilizar las siguientes:

• js (la sugerida por el enunciado)
• MediaPipe Task Vision código abierto de Google

Finalmente se escogió MediPipe por dos razones de peso una de ellas abordando las capacidades tecnológicas del modelo y la otra de capacidad de trabajo. Y es que la primera son los 478 puntos de referencia que MediaPipe coge de la cara lo que da un grado mucho mayor de precisión y la segunda es la capacidad de delegar el trabajo a la CPU creando programas mucho más factibles a nivel de rendimiento.

3.     Arquitectura y estructura del código

Para no entrar en detalle muy técnico voy a indicar de forma general la estructura de este código:

• Tenemos el archivo man.js que es la entrada de Electron quien gestiona las ventanas, permisos y arranca el proyecto como tal.
• html carga la HUD es decir la parte visual y los diferentes scripts.
• css solicitado por el enunciado independiente y desarrollado por nosotros, con fuentes de Google fonts de Halloween, por ejemplo.
• js y particleSystem.js gestionan los estilos, timings y condicionales de las partículas
• js se encarga de definir las constantes globales, como por ejemplo el parámetro de obertura de boca.

4.     Decisiones estéticas

La paleta de colores y el estilo del proyecto se han establecido en base a diferentes referencias que he encontrado por internet, de todas estas he localizado los colores comunes que son los siguientes y los que se han utilizado finalmente en el proyecto.

1. Malva / Violeta (#6B2D7B, #4A1D5C) — color principal de fondo y elementos de la UI
2. Naranja dorado (#E8A030) — color secundario, presente en el HUD y en los elementos de calabaza.
3. Crema (#FFF5E6) — color base del texto y de los fantasmas, aporta calidez y contraste suave.
4. Coral (#E85D3A) — usado en botones y acentos, da vida y energía a la interfaz.
5. Amarillo (#F5C518) — para los detalles brillantes y las chispas.

5. Flujo de desarrollo

Durante la creación de este proyecto se ha ido iterando en diferentes ideas y conceptos para acabar teniendo una propuesta completa como la de ahora.

Por ejemplo, en un principio se propuso la idea de crear una serie de minijuegos llegados a un porcentaje de progreso, estos minijuegos estaban pensados para utilizar otras características de MediaPipe como son detectar el movimiento de los ojos o las diferentes formas que podía crear la boca. Esto en un inicio me pareció una buena idea, pero luego vi que rompía con el principio de la idea propuesta y la desestimé.

Otra idea que tuve y que si que esta en la propuesta final es el uso de recompensas visuales para tener al usuario activo y animarle a seguir con la actividad. A este recurso le llamo “anillos dinámicos” y funciona de la siguiente forma: se trata de un círculo que decrece alrededor de la boca del usuario y que al hacerse completamente pequeño explotan muchas partículas dando ese subidón para seguir jugando.

6. Enlaces

GitHub: https://github.com/Ramonet02/PEC-2.git

p5.js Editor: p5.js Web Editor | Halloween smiles

La idea surgió de forma bastante rápida ya que quería representar el reloj como si fuese un ser vivo por lo que la idea de implementar animales resulto muy orgánica. La reinterpretación de la hora además del propio estilo de los números es la representación de los segundos de la que estoy muy orgulloso ya que mediante el visual se entiende el paso del tiempo. Hay 60 puntos de luz que se iluminan de forma progresiva, cuando el último de estos se ilumina se cambia la hora del reloj con una animación sutil.

El mayor reto a nivel de programación ha sido la creación del diseño y de la lógica de los números ya que algunos están formados por mas de una serpiente y la coherencia de diseño es importante.

La paleta de colores esta escogida representando los colores de la jungla.

Serpenr Clock