Skip to content
elopositorPublic

About

App de bienestar nutricional para grupos pequenos: subes lo que comes, el grupo lo puntua y sale un ranking. Diseno de producto, arquitectura Kotlin/Compose + Firebase y prototipo web funcional.

Topics

Resources

Stars

0 stars

Watchers

0 watching

Forks

Latest commit

 

History

4 Commits

Folders and files

NameName
Last commit message
Last commit date
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

Food Rank Challenge

App de bienestar para grupos pequeños: subes lo que comes, el grupo lo puntúa,
y la app cruza esas comidas con cómo te encuentras después.

Kotlin Jetpack Compose Firebase Hilt Gemini Licencia MIT


La idea

Comer mal casi nunca es un problema de información: es un problema de inercia. Sabes lo que deberías comer y aun así abres la nevera y coges lo de siempre, porque nadie lo ve y no pasa nada.

Food Rank Challenge le pone testigos. Cada comida se fotografía y el resto del grupo la puntúa sobre unos criterios que el propio grupo define. Y como la app registra también cómo te encuentras —digestión, piel, energía, sueño—, con el tiempo deja de ser un juego y empieza a enseñar qué comidas te sientan mal.

No es una red social. Está pensada para grupos cerrados con relación real entre ellos: pareja, familia, compañeros de piso. Diseñarla para desconocidos destruiría lo único que la hace funcionar, que es que te importe quién puntúa.

La app

Feed del grupo Evaluar una comida Bienestar diario Seguimiento de la piel
Feed con las comidas del grupo y las pendientes de evaluar Pantalla de evaluación con varios parámetros y su media Registro diario de ánimo, energía, sueño y ansiedad Mapa facial con el histórico de marcas por fecha

Seis secciones: Inicio (el feed y lo que tienes pendiente de puntuar), Ranking (diario, semanal, mensual y global), Bienestar, Piel, Digestión y Mi perfil.

Lo que más se sale de lo previsto es el módulo digestivo: registro de deposiciones con escala de Bristol, gases, síntomas, etiquetas de alimento propias, índices calculados y un sistema de avisos (HealthWarning) que salta, por ejemplo, tras tres días sin deposición. Tiene además sus propios ajustes de privacidad, porque no todo lo que se registra ahí se comparte con el grupo.

Cómo funciona

flowchart TD
    A["Subes la comida<br/>foto + tipo + comentario"] --> B["Queda pendiente<br/>para el resto del grupo"]
    B --> C["Cada miembro la puntúa<br/>sobre los parámetros del grupo"]
    C --> D["Media de la comida"]
    D --> E["Ranking diario,<br/>semanal y global"]
    A --> F["Evaluación automática<br/>con Gemini"]
    G["Registro de bienestar,<br/>piel y digestión"] --> H["Cruce comida ↔ cómo te sienta"]
    B -.->|"push"| I["Aviso: tienes<br/>comidas por puntuar"]
Loading

Tres reglas sostienen el diseño:

  • No puedes puntuarte a ti mismo. Sin eso el ranking no vale nada.
  • Lo pendiente se ve. Las comidas sin puntuar salen destacadas y generan aviso, porque un ranking a medio votar no dice nada.
  • Los criterios los pone el grupo. Cantidad, valor nutricional, adecuación y presentación son solo los de partida: se pueden cambiar, reordenar y añadir los propios.

Arquitectura

MVVM sobre Clean Architecture en tres capas, con Hilt inyectando las dependencias. El código recuperado enseña 9 repositorios, 38 modelos de dominio y 14 módulos de pantalla.

Capa Cómo está resuelto
UI Jetpack Compose y Material 3, con Compose Navigation
Inyección Hilt (Dagger)
Datos Cloud Firestore, 15 colecciones (meals, evaluations, skin, bowelMovements, parameters…)
Sesión Firebase Auth anónimo; el usuario entra por nombre contra la colección users y la sesión se guarda en SharedPreferences
Imágenes Se comprimen a JPEG al 85 % en el dispositivo antes de subirlas
IA Gemini 2.5 Flash evalúa la comida a partir de la foto
Avisos Firebase Cloud Messaging, más recordatorios locales con AlarmManager que sobreviven al reinicio
Mínimo Android 8.0 (API 26)

El código

El proyecto Android original se perdió. En referencia/ está el código de la v19 recuperado con jadx a partir de la APK: no compila tal cual —es Java descompilado de Kotlin— pero conserva íntegra la estructura y la lógica, y basta para reconstruir la app. El LEEME explica qué se conserva, qué son los artefactos del compilador y cómo regenerarlo.

Se conservan además los dos documentos con los que se diseñó, que siguen siendo la mejor puerta de entrada al proyecto:

🧭 Estrategia de producto Para quién es, qué problema resuelve, qué entra en el MVP y qué se deja fuera
🏗️ Arquitectura técnica Stack, modelo de datos, reglas de seguridad, notificaciones y plan por sprints

El prototipo

Antes de la app hubo un prototipo del flujo completo: un HTML autocontenido, sin dependencias ni servidor, que guarda en localStorage. Se abre con doble clic prototipo-web/index.html y se recorre el circuito entero.

Ver el prototipo
Feed Subir comida Ranking
Feed del prototipo Pantalla de subir comida del prototipo Ranking del prototipo

Decisiones de producto

Lo interesante no es solo lo que hace, sino dónde la realidad se apartó del plan:

Decisión Qué pasó
Grupos cerrados de 2 a 15 personas Se mantuvo. Con desconocidos las puntuaciones dejan de importar
Sin conteo de calorías Se mantuvo. Hay veinte apps que lo hacen mejor y ninguna consigue que las uses tres meses
Fotos comprimidas antes de subir Se mantuvo, al 85 % de calidad. Una foto de 4 MB por comida agota cualquier plan gratuito en semanas
El registro de síntomas fuera del MVP No se cumplió. El documento de producto recomendaba dejarlo fuera porque mezcla lo social con lo íntimo. Acabó siendo el módulo más desarrollado de la app, y con razón: es lo que convierte el juego en algo útil. La solución al conflicto no fue quitarlo, sino darle ajustes de privacidad propios
Gamificación aplazada a la fase 2 Se cumplió. Medallas y rachas siguen sin estar; primero tenía que funcionar el circuito
Parámetros de evaluación fijos Se quedó corto. Acabaron siendo configurables por el usuario, con orden y valores por defecto propios

Estado y deuda técnica

Es un proyecto en uso real, no un ejercicio, y tiene lo que tienen los proyectos en uso real:

  • Había una clave de API en el código. La de Gemini estaba escrita como literal y, por tanto, embebida en la APK. Se retiró de la copia publicada y el 31-08-2026 se revocó y rotó: la clave que circula en las APK antiguas ya no funciona. La evaluación por IA queda fuera de servicio en la v19 hasta reconstruir la app sirviendo la clave desde un backend o Remote Config, nunca como literal.
  • Las fotos van a un alojamiento público. Se suben a catbox.moe sin autenticación, así que quien tenga la URL ve la imagen. Para fotos de comida de un grupo cerrado, lo coherente es Firebase Storage con reglas por grupo.
  • Lo que se distribuye es un build debug, sin minificar ni ofuscar.
  • La APK no se publica aquí, ni como release ni como artefacto: la app se conecta a una base de datos real con datos de personas.

Licencia

MIT · Alejandro Valero Collante

About

App de bienestar nutricional para grupos pequenos: subes lo que comes, el grupo lo puntua y sale un ranking. Diseno de producto, arquitectura Kotlin/Compose + Firebase y prototipo web funcional.

Topics

Resources

Stars

0 stars

Watchers

0 watching

Forks

Releases

Packages

Contributors

Languages