HTML5
CSS3
JavaScript
React.js
Angular
Next.js
TailwindCSS
Node.js
Express.js
PHP
Python
Go
PostgreSQL
MySQL
MongoDB
Flutter
Dart
Kotlin
Git & GitHub
Firebase
Docker
FridgeBoss: Gestión de Inventario Inteligente y Gamificación contra el Desperdicio de Alimentos
Problema Inicial: El Desafío del Desperdicio Colectivo y la Inconsistencia de DatosEl desperdicio de alimentos en los hogares no es solo un problema ético y ambiental de gran escala; es un reflejo directo de la falta de herramientas tecnológicas eficientes para la gestión de inventarios domésticos. Los usuarios se enfrentan a un problema triple en su rutina diaria: la fricción de registrar manualmente cada ingrediente que compran, la incapacidad de recordar qué alimentos están próximos a vencer sin abrir físicamente la nevera, y la falta de ideas gastronómicas creativas para aprovechar los ingredientes sobrantes en estado crítico.Desde una perspectiva puramente de ingeniería de software, las pocas aplicaciones que intentaban resolver esto sufrían de tres fallas de arquitectura críticas:Fricción en la Entrada de Datos: Obligar al usuario a escribir el nombre, precio y cantidad de 30 productos comprados en un supermercado destruye la retención de la aplicación en los primeros tres días.Dependencia Absoluta de Conexión: Las aplicaciones basadas 100% en la nube quedaban inutilizadas dentro de cocinas con mala cobertura de red o sótanos de supermercados.Amnesia de Segundo Plano: La falta de persistencia en tareas del sistema operativo provocaba que las alertas de vencimiento se perdieran si el usuario cerraba la aplicación de forma forzada o reiniciaba el dispositivo.Arquitectura de Solución: Un Enfoque Local-First y Guiado por IAPara resolver estas limitaciones de forma definitiva, diseñé la arquitectura de FridgeBoss bajo el paradigma Local-First, asegurando que el núcleo de la aplicación funcione al 100% sin conexión a internet, delegando las tareas pesadas de inteligencia computacional a microservicios asíncronos y desacoplados.Elegí rigurosamente cada componente del stack tecnológico basándome en principios de escalabilidad, rendimiento y mantenibilidad:Clean Architecture y MVVM: Separé la aplicación en tres capas independientes (Data, Domain, Presentation). La capa de presentación no sabe cómo se guardan los datos, y la capa de dominio solo contiene las reglas de negocio puras escritas en Kotlin. Esto permite que el sistema sea testeable mediante pruebas unitarias modulares.Jetpack Compose y Material Design 3: Toda la interfaz de usuario se renderiza de forma declarativa mediante Compose, eliminando por completo los antiguos layouts en archivos XML. Esto reduce las líneas de código de UI en un 40% y garantiza animaciones fluidas impulsadas directamente por la aceleración de hardware del dispositivo móvil.Room Database y SQLite: Actúa como la "Única Fuente de la Verdad" (Single Source of Truth). Almacena de manera relacional el inventario completo, los metadatos de los comercios locales y el historial. Al exponer los datos mediante flujos reactivos de Kotlin (Flow), la UI se actualiza de forma automática e inmediata en el instante exacto en que la base de datos local sufre una modificación.Google Gen AI SDK (Gemini): Integré los modelos Gemini 1.5 Flash y Pro directamente en el cliente mediante inyección en tiempo de compilación. Para el OCR de tickets, en lugar de recibir texto plano caótico, forcé al modelo a responder bajo un JSON Schema estructurado y estricto. Esto garantiza que el backend de la app siempre reciba un objeto predecible con tipos de datos limpios (Strings, Integers, Floats).Jetpack DataStore Preferences: Reemplacé el antiguo e inseguro SharedPreferences por DataStore para gestionar el bucle de hábito de la gamificación (Rachas y Dinero Salvado). Al correr de forma asíncrona sobre Corrutinas de Kotlin, se evitan por completo los bloqueos de lectura/escritura en el hilo principal de la aplicación, anulando el riesgo de congelamiento de pantalla.Retos de Implementación: El Obstáculo más DifícilEl desafío técnico más complejo de la ingeniería del proyecto fue sincronizar de forma persistente y resiliente las notificaciones del sistema operativo con el estado cambiante de la base de datos local de Room sin drenar la batería del usuario ni violar las políticas estrictas de optimización de memoria de las versiones modernas de Android (Android Oreo a Android 14).La solución tradicional de usar un Service persistente en primer plano consumiría recursos excesivos. Para resolverlo, implementé una arquitectura reactiva desacoplada utilizando WorkManager, asegurando la ejecución de una tarea en segundo plano programada de forma diaria a las 9:00 AM, la cual despierta el hilo de ejecución por breves segundos, consulta la base de datos local y construye canales de notificación con prioridades del sistema adecuadas.A continuación, muestro una simplificación de la lógica central del Worker encargado de auditar la base de datos en segundo plano sin interrumpir la experiencia del usuario:class InventoryNotificationWorker( context: Context, workerParams: WorkerParameters, private val ingredientRepository: IngredientRepository // Inyectado mediante Clean Architecture ) : CoroutineWorker(context, workerParams) { override suspend fun doWork(): Result = withContext(Dispatchers.IO) { try { // 1. Consultamos de forma asíncrona en el hilo de Entrada/Salida (I/O) val criticalIngredients = ingredientRepository.getIngredientsNextToExpire(daysThreshold = 2) if (criticalIngredients.isNotEmpty()) { // 2. Si existen ingredientes críticos, disparamos el canal de alerta nativo triggerSystemNotification(criticalIngredients) } Result.success() } catch (e: Exception) { Log.error("API_WORKER_FAILURE", "Fallo al escanear inventario local", e) Result.retry() // Si la consulta falla por bloqueo, WorkManager reintenta con Backoff elástico } } private fun triggerSystemNotification(ingredients: List<Ingredient>) { val notificationManager = applicationContext.getSystemService(Context.NOTIFICATION_SERVICE) as NotificationManager // Configuración de Canales de Notificación de alta prioridad requerida para Android Oreo en adelante if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.O) { val channel = NotificationChannel( "FRIDGE_BOSS_ALERT_CHANNEL", "Alertas Críticas de Inventario", NotificationManager.IMPORTANCE_HIGH ) notificationManager.createNotificationChannel(channel) } val message = "¡Atención! Tienes ${ingredients.size} alimentos próximos a vencer. Abre el Chef IA para rescatarlos." val notification = NotificationCompat.Builder(applicationContext, "FRIDGE_BOSS_ALERT_CHANNEL") .setSmallIcon(R.drawable.ic_notification_leaf) .setContentTitle("🛡️ Rescate de Comida Requerido") .setContentText(message) .setPriority(NotificationCompat.PRIORITY_HIGH) .setAutoCancel(true) .build() notificationManager.notify(1001, notification) } } Resultados de Rendimiento: Optimizaciones y Métricas de ImpactoGracias a las decisiones de diseño arquitectónico tomadas, FridgeBoss no solo es una aplicación visualmente atractiva, sino una pieza de software altamente eficiente:Procesamiento Asíncrono a 0ms en Main Thread: Al canalizar absolutamente todas las consultas de Room y las escrituras de DataStore a través de Kotlin Coroutines utilizando estrictamente Dispatchers.IO, logré que la aplicación mantenga una tasa de refresco fluida de 60 FPS estables, sin registrar un solo error de ANR (Application Not Responding) en las pruebas de estrés de la interfaz.Eficiencia en el Procesamiento de Imagen por OCR: Al forzar salidas estructuradas JSON directamente en el SDK de Gemini, el tiempo de parseo en el cliente se redujo de segundos de procesamiento de texto sucio a milisegundos de asignación de variables directas. El backend móvil puede leer e instanciar un ticket de compra con 20 productos en menos de 1.5 segundos promedio una vez recibida la respuesta del modelo Flash.Persistencia de Estado Robusta y Gamificación: El ciclo de vida de la racha es completamente inmune a fallos del sistema o cierres repentinos de la app. Si un usuario deja vencer un alimento, la penalización se calcula de forma atómica en Room y altera el DataStore de manera reactiva, manteniendo la sincronización entre la base de datos SQLite y la memoria caché de la UI con un impacto de memoria RAM despreciable en el dispositivo del usuario.Impacto Arquitectónico Final: FridgeBoss demuestra que es perfectamente viable construir aplicaciones móviles modernas que aprovechen las capacidades avanzadas de modelos de Inteligencia Artificial generativa manteniendo una huella de carbono y de consumo de recursos local mínima, respetando el ciclo de vida del sistema operativo y garantizando una experiencia de usuario sedosa, fluida y con propósito ambiental.
