La Raya · app (5): gastronomía con mapa, un contacto sin datos y un perfil que dice qué versión llevas

Última entrada del diario de la app de La Raya. Aquí la parte móvil se pone al día con lo que el backend había construido: la sección de gastronomía, un canal de feedback y un perfil más útil.

Gastronomía: enseñar los datos sin engañar

El backend empezó a devolver, por cada local, campos nuevos: web, horario, latitud, longitud y descripción. Primer aprendizaje, muy de TypeScript: si el tipo no incluye un campo, se descarta en silencio. Así que lo primero fue ampliar el tipo del local con esos campos; si no, por mucho que el backend los enviara, la app los tiraba.

En el detalle del local:

"Cómo llegar" usa las coordenadas cuando existen y, si no, la dirección (que muchas veces es más precisa que un pin al centro del pueblo).
Botón Web cuando el local tiene sitio, y botón Compartir (nombre + localidad + web).
Tarjetas de dirección, horario y la descripción.

Y un par de decisiones de honestidad con el usuario:

El horario lleva un aviso: "orientativo, puede variar; confírmalo con el local", porque viene de fuentes que no siempre están al día.
Por esa misma razón quité el horario de la tarjeta (a simple vista, un horario desactualizado confunde más que ayuda) y lo dejé solo en el detalle.
Y se muestra la atribución a OpenStreetMap, que su licencia exige.

Mostrar un dato con su nivel de confianza es más útil (y más honrado) que mostrarlo como verdad absoluta.

Contacto: feedback sin pedir nada

El backend ofrece un formulario de contacto que no guarda datos personales (su serie lo cuenta). La app pone la cara visible: una pantalla con un tema cerrado (una opción por sección + "Problema técnico" + "Otros") y un mensaje libre, con sus estados de carga, error y éxito, y un mensaje claro cuando se alcanza el límite diario.

Para el anti-abuso sin identificar a nadie, la app genera un UUID de dispositivo persistente (en almacenamiento seguro) y lo manda en una cabecera. El backend lo usa para limitar a 5 mensajes/día sin necesidad de saber quién hay detrás. Cero campos de email o nombre: si no se piden, no se guardan.

Perfil: que las pruebas no sean a ciegas

Una petición muy práctica para las pruebas cerradas: saber qué estás probando. El perfil ahora tiene una tarjeta "Estado y versión" con:

Estado del API: un ping al endpoint /health/ que muestra "Operativo" / "No disponible" (y se toca para refrescar). Aquel /health/ de juguete que monté peleándome con el healthcheck en producción resultó tener un segundo uso.
Versión y build de la app, leídos en runtime, para que no haya duda de qué binario lleva cada tester.

Y desde ahí mismo, el acceso al formulario de contacto.

Lo que me llevo (y cierre de la serie)

Tu tipo es tu contrato. Si la app no declara un campo, no lo verá aunque llegue. Mantener los tipos al día con la API evita "datos fantasma".
Muestra los datos con su confianza. Un horario con aviso de "orientativo" es mejor producto que un horario presentado como dogma.
Pide lo mínimo. Un contacto sin datos personales y un anti-abuso por UUID anónimo dan feedback sin construir un perfil de nadie.
Facilítate las pruebas. Ver estado del API y versión en el perfil convierte un "no sé qué build tienes" en un vistazo.

Y con esto se cierra el diario de la app de La Raya: de un esqueleto Expo a una guía bilingüe de la frontera, enfocada (sin GPS que nadie pedía), publicable en Play y al día con un backend que no para de crecer. La otra mitad de la historia está en la serie del backend. Gracias por leer hasta aquí.