Victor Arias
AudioEmoticones es un teclado para Android que sustituye al del sistema y añade emoticonos que suenan al enviarlos: los packs se descargan desde la app, las preferencias del usuario se sincronizan entre dispositivos y el equipo publica el catálogo desde su propio panel. El backend corre sobre AWS, aguantó más de 100.000 descargas y redujo la latencia un 35%.
| Cliente | AudioEmoticones |
| Sector | App de teclado para Android |
| Servicio | Servicios Cloud |
| Tecnologías | App Android, AWS, Backend en la nube, Teclado con emoticonos de audio, Packs descargables, Sincronización de preferencias, Panel de contenido |
| Duración | 1-2 meses |
| Nuestro rol | Infraestructura y backend en la nube sobre AWS para el teclado Android: packs de emoticonos descargables, sincronización de preferencias entre dispositivos, escalado para los picos de descargas y panel de contenido. |
| Publicado | 10 de enero de 2023 |
Un teclado no se acaba en la app que se instala: si el producto incluye contenido descargable, cada pack que llega pesa, se actualiza y tiene que estar disponible sin que el usuario note esperas mientras escribe. La nube deja de ser soporte y pasa a ser parte del producto.
AudioEmoticones es un teclado para Android con emoticonos que suenan al enviarlos, montado sobre un backend en la nube en AWS: packs descargables, sincronización de preferencias entre dispositivos y un panel propio para publicar el catálogo. El sistema aguantó más de 100.000 descargas y redujo la latencia un 35%.
El reto: contenido que se descarga y se actualiza solo
Un teclado con catálogo propio tiene tres frentes abiertos a la vez: servir el contenido, conservar la configuración del usuario y permitir que el equipo publique sin depender de nadie. Los tres pasan por el backend, no por la app.
El contenido pesa
Meter todos los emoticonos dentro de la instalación inicial haría la app más grande y cada novedad obligaría a una actualización. Servirlos desde la nube permite que la descarga inicial sea ligera y que el catálogo crezca después, sin tocar la app instalada.
El usuario espera encontrar lo suyo
Quien cambia de teléfono o usa también una tablet espera que su configuración esté donde la dejó. Si las preferencias viven solo en el dispositivo, cada cambio es empezar de cero, y en una app de uso diario eso se nota a la primera.
Publicar no puede depender de la tienda de apps
Cuando el catálogo es el producto, la velocidad para publicarlo importa: si cada emoticono nuevo exige una actualización revisada por la tienda, cualquier campaña llega tarde. El equipo necesita publicar por su cuenta y ver el resultado el mismo día.
La solución: backend en la nube sobre AWS
El backend se montó sobre AWS, con el servicio de packs descargables, la sincronización de preferencias y un panel desde el que el equipo publica el catálogo. La infraestructura se dimensionó para los picos de descargas y se monitorizó desde el principio.
El teclado tiene que responder al instante: el contenido que se descarga no puede notarse al escribir.
Packs descargables servidos desde la nube
Los emoticonos llegan en packs que la app descarga y guarda en el dispositivo, servidos desde la nube. Así la instalación inicial se mantiene ligera y el catálogo puede crecer o cambiar sin publicar una versión nueva en la tienda de aplicaciones.
Sincronización de preferencias entre dispositivos
Las preferencias del usuario se guardan en el backend, de modo que cambiar de móvil o usar una tablet no supone reconfigurar nada. Es una función silenciosa: solo se nota cuando falta, y cuando falta se convierte en motivo para desinstalar.
Panel de contenido y escalado automático
El equipo publica y retira emoticonos desde su propio panel, sin depender de nadie y sin esperar revisiones. Al mismo tiempo, la infraestructura en AWS escala cuando llega un pico de descargas, para que un lanzamiento con éxito no se convierta en una caída.
Cómo lo implementamos en uno a dos meses
El proyecto empezó por medir el comportamiento real de la app: cuánto tarda en servir un pack, qué se descarga más y cuánta gente coincide en los picos. Con esos números se dimensionó la infraestructura y se fijó el objetivo de latencia.
El audio es la parte del producto que más se nota si el contenido llega tarde o a medias.
Medir la latencia antes de tocar nada
Antes de cambiar la infraestructura se midió cuánto tardaba la app en servir cada pieza de contenido. Sin ese dato no se sabe si el problema está en la nube, en la app o en el tamaño del pack, y se acaba optimizando a ciegas.
Publicar un pack de prueba de principio a fin
El circuito completo se probó con un pack real: crearlo, publicarlo desde el panel, descargarlo en un dispositivo limpio y comprobar que aparece en el teclado. Es la prueba que demuestra que el equipo puede publicar solo, sin tocar la app ni esperar a nadie.
Resultados
El proyecto se entregó con el servicio de packs en marcha, la sincronización de preferencias y el panel de contenido operativo. Estas fueron las necesidades y cómo se resolvieron:
| Necesidad | Cómo se resolvió |
| Servir los emoticonos sin engordar la app | Packs descargables servidos desde la nube |
| Que el usuario conserve su configuración | Sincronización de preferencias entre dispositivos |
| Publicar contenido sin actualizar la app | Panel de contenido propio del equipo |
| Aguantar el pico de descargas | Escalado automático en AWS |
| Que el teclado responda al instante | Latencia un 35% menor |
Los resultados medidos del proyecto: más de 100.000 descargas y una latencia un 35% menor. Los dos datos se explican juntos: el contenido se sirve desde la nube para que la app no cargue de más, y responde rápido porque la infraestructura está dimensionada para la demanda real.
Qué necesita una app con contenido descargable
Si tu app reparte contenido y no solo funciones, estos son los puntos que deciden si aguanta:
- Contenido servido desde la nube, para que la instalación inicial sea ligera y el catálogo crezca sin actualizar la app.
- Packs descargables con una descarga fiable, porque un pack a medias se nota en el uso diario.
- Sincronización de preferencias, para que cambiar de dispositivo no sea empezar de cero.
- Un panel para publicar contenido sin depender de la tienda de aplicaciones ni de terceros.
- Infraestructura que escale cuando el contenido se populariza de golpe.
- Latencia medida, no supuesta: es lo que se nota en cada interacción con la app.
Si tu app reparte contenido y quieres que la nube no sea el cuello de botella, en la página de servicios cloud contamos cómo trabajamos, y puedes escribirnos para revisarlo juntos.
Preguntas frecuentes
¿Qué tiene de particular un teclado con contenido descargable?
Que el producto no es solo el teclado: es el catálogo que va por detrás. Cada pack pesa, se descarga y se actualiza, así que la app depende de la nube para servir contenido sin engordar la instalación inicial y sin que el usuario note esperas al escribir.
¿Por qué sincronizar las preferencias entre dispositivos?
Porque el usuario que cambia de móvil o usa una tablet espera encontrar su configuración como la dejó. Si las preferencias viven solo en el teléfono, cada cambio de dispositivo es empezar de cero, y eso es motivo suficiente para desinstalar.
¿Qué aporta un panel de contenido propio?
Publicar y retirar emoticonos sin tocar la app ni esperar a una actualización de la tienda de aplicaciones. En una app de contenido eso es la diferencia entre reaccionar a una campaña en un día o quedarse esperando la revisión de la store.
¿Cuánto tarda una app con backend en la nube?
Este proyecto se entregó en uno a dos meses. El calendario lo marcan el servicio de packs descargables, la sincronización de preferencias, el panel de contenido y el dimensionado de la infraestructura para los picos de descargas.
