Resumen del proyecto
Jepta es una red social hiperlocal construida alrededor del sitio donde vives. En lugar de un grafo global de seguidores, organiza a las personas por proximidad: chats asociados a una dirección o a un edificio, chats de grupo para quienes los comparten y canales que gestionan la panadería, el taller o el club que está a unos cientos de metros. Todo en la app —los chats que se te ofrecen, los canales del feed, las publicaciones que ves primero— se ordena por la distancia desde donde estás.
Netgineers GmbH acudió a nosotros con el producto definido y el backend ya en marcha, y necesitaba construir la parte móvil: una sola base de código Flutter para iOS y Android, para un producto con una superficie inusualmente amplia para una primera versión.
Onboarding
Permiso de ubicación
Lista de chats
Feed del canal
Información del canal
Chat del canal
Nueva publicación
El reto
Dos cosas convirtieron esto en algo más que un desarrollo estándar.
El tamaño de la superficie de pantallas
Jepta no es una funcionalidad con ajustes alrededor. Chats directos, chats de grupo, chats por dirección, un feed de canales, perfiles de canal con horarios y galerías de fotos, conversaciones entre canal y usuario, un editor de publicaciones con control de comentarios en cada una, una pestaña de actividad, una de perfil, búsqueda, alta de contactos por código QR, ubicación y flujos de permisos —todo en la primera versión y en una ventana de seis meses. A ese volumen, las pantallas dejan de ser unidades de trabajo independientes: sin un esqueleto común, cada nueva arrastra sus propias rarezas de navegación, sus propios estados de carga y de vacío y su propia copia de la misma lista.
Tiempo real en todas partes
El chat es el lugar evidente donde aparecen las conexiones WebSocket, pero en Jepta no se limitan a él. Una publicación que llega a un canal, un contador de comentarios que se mueve, el indicador de no leídos en la pestaña de chats, un mensaje marcado como leído —todo lo mueve la misma conexión viva, incluso en pantallas que el usuario no está mirando. Resolverlo pantalla a pantalla habría significado una conexión por pantalla y un estado que se contradice a sí mismo en cuanto se cambia de pestaña.
Nuestro enfoque
Tratamos ambos problemas como uno solo: construir primero las piezas compartidas y dejar que las pantallas fueran delgadas.
Una capa de tiempo real, muchos consumidores
La conexión WebSocket vive por debajo de la interfaz como un único cliente dueño de su propio ciclo de vida: conectar, autenticar, heartbeat, reconectar con backoff, volver a suscribirse. Las pantallas no abren sockets; se suscriben a flujos de eventos tipados y reciben las actualizaciones. Los mensajes enviados mientras la conexión está caída se encolan y se vacían al reconectar en lugar de perderse, y el estado de entrega (enviado, entregado, leído) forma parte del modelo del mensaje en vez de deducirse de lo que haya llegado. Como la capa es compartida, un mensaje que aterriza en el chat abierto y un contador de no leídos que sube en una pestaña que nadie mira son el mismo evento tratado una sola vez.
Un esqueleto de pantalla en lugar de artesanía pantalla a pantalla
Con tantas superficies, la ganancia estaba en hacerlas uniformes: un grafo de navegación con rutas tipadas, un mismo patrón de Gestión de estado aplicado igual en cada funcionalidad y un conjunto compartido de estados de lista, carga, vacío y error. Las pantallas nuevas fueron sobre todo composición —que es lo que hizo abordable el volumen dentro del plazo y lo que mantuvo la app coherente en lugar de parecer veinte pantallas hechas por manos distintas.
La ubicación como entrada de primera clase
La proximidad no es un filtro añadido al feed, es el principio que organiza el producto, así que la capa de ubicación tenía que ser fiable: flujos de permisos que se degradan con elegancia cuando el usuario dice que no, coordenadas cacheadas para que el feed nunca esté en blanco mientras se obtiene la posición, y la distancia mostrada junto al contenido («a 5 km» en la cabecera del canal) para que el orden se entienda en vez de resultar misterioso.
Resultados
Jepta salió a iOS y Android desde una sola base de código Flutter dentro de la ventana de seis meses, y con el conjunto de funcionalidades completo: chats, canales, publicaciones, comentarios y el feed por cercanía en la primera versión, no repartidos en varias.
Lo que sobrevivió al plazo fue la arquitectura. Como la capa de tiempo real, el grafo de navegación y el patrón de estado se construyeron una vez y se reutilizaron, añadir una pantalla después del lanzamiento siguió siendo un cambio pequeño y no una nueva integración con el socket, el router y la caché. Para un producto cuyo roadmap es «más superficies», esa es la diferencia que se acumula.
Lo que me preocupaba eran los seis meses para una app tan amplia. Jepta son chats de vecindario, canales de negocios, publicaciones, comentarios y un feed que se reordena alrededor de donde estés: una lista larga de pantallas, una fecha fija y la expectativa realista de que la mitad se iría a una segunda versión.
Nerdy Production construyó primero los cimientos compartidos —una capa de tiempo real, un modelo de navegación— y a partir de ahí cada pantalla nueva salió barata. Lanzamos en iOS y Android con el conjunto completo de funcionalidades, el chat ha sido fiable desde el primer día y ampliar la app desde entonces ha sido una tarea pequeña, no un proyecto. Recibimos el producto que especificamos, en la fecha que especificamos.
Preguntas frecuentes
Jepta se construyó dentro de nuestro servicio de desarrollo de apps con Flutter —la misma práctica que hay detrás de nuestro otro trabajo Flutter en tiempo real.