20.671 - Desarrollo de aplicaciones interactivas - Aula 1

Pública

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.