El proceso de convertir una app de Android en una página web

• Travelbound, que muestra itinerarios de viaje, información de hospedaje y PDF, en realidad mostraba contenido recibido desde la web e incluso incluía rastreo y publicidad de viajes, así que se probó reemplazarla por una página web con la misma información
• Al rootear un dispositivo virtual de Android e interceptar el tráfico con HTTP Toolkit, se confirmó que una API que concatenaba el nombre de usuario y la contraseña en la URL devolvía en JSON todo el contenido de la app
• Con un script en Ruby y Cron se obtiene periódicamente el JSON más reciente y se genera HTML, exponiendo solo los archivos necesarios como itinerarios y PDF, mientras se excluyen los datos publicitarios
• La versión web permite copiar, imprimir, guardar, crear marcadores y buscar, funciona en una mayor variedad de dispositivos y además elimina el código de rastreo y los anuncios de la app original
• Mientras que la app original pasa de 43 MB a 124 MB después de descargar el contenido, la página web ocupa 0.05 MB y las imágenes opcionales solo 35 MB, por lo que la web es más adecuada para contenido documental entregado en HTML y HTTP

---

Travelbound, que bien pudo haber sido una página web

• Para revisar el itinerario del viaje a Disneyland, el transporte y la información de hospedaje de la escuela de artes escénicas a la que irá el hijo del autor, era necesario instalar la app Travelbound
• El contenido principal de la app se entregaba por la web como texto, imágenes y enlaces a PDF
• Las funciones que la diferenciaban de una página web eran dos y perjudicaban al usuario
  • Enviaba al desarrollador datos de rastreo vinculados con la Google Account
  • Publicitaba otros productos de viaje operados por la misma agencia bajo el nombre inspirations
• En una página web el contenido se puede copiar, imprimir, guardar, crear marcadores y buscar, además de poder usarse en casi cualquier dispositivo y con potencialmente mejor accesibilidad

Interceptar el tráfico de una app de Android

• Se creó un nuevo dispositivo virtual en Virtual Device Manager de Android Studio y se verificó que adb shell funcionara
• Se rooteó un dispositivo virtual con Android 33 usando rootAVD

  ./rootAVD.sh system-images/android-33/google_apis_playstore/x86_64/ramdisk.img  
  

• El rooteo era necesario para hacer que una app que usa Certificate Pinning confiara en el certificado TLS autofirmado del proxy intermediario
  • Sin root, apps como Travelbound consideraban inválido el certificado y rechazaban la comunicación
• Después de un arranque en frío, se ejecutó Magisk y se configuró para permitir automáticamente el acceso su a las apps que lo solicitaran
  • Si no se permitía automáticamente, HTTP Toolkit se ejecutaba en modo no privilegiado sin esperar la respuesta del usuario
• Se interceptó el tráfico del dispositivo virtual de Android con HTTP Toolkit
  • Instala un proveedor de VPN falso para enviar el tráfico del dispositivo al proxy
  • Debido a las restricciones de seguridad de Android, el certificado raíz CA instalado tuvo que agregarse manualmente
• Después de instalar Travelbound desde Play Store, se configuró el proxy para pasar solo el tráfico de esa app y así reducir el ruido

Llamadas a la API y estructura de los datos

• La app llamaba una URL de API con el siguiente formato, concatenando el nombre de usuario y la contraseña del grupo de viaje

  https://travelbound.api.vamoos.com/api/itineraries/…}  
  

• El nombre de usuario y la contraseña eran credenciales compartidas por todo el grupo de viaje
• El JSON de respuesta de la API contenía todo el contenido que mostraba la app
  • Un arreglo con cada tramo del itinerario del viaje
  • Un arreglo de anuncios inspirations
  • Un arreglo de referencias cruzadas con archivos como imágenes usados por otras secciones
• Incluso el código HTML que la app iba a mostrar venía incluido en los datos, así que la forma de entregar el contenido ya era similar a una página web
• Las URL de imágenes en S3 tenían un tiempo de expiración relativamente corto, por lo que era necesario volver a obtener el JSON periódicamente aunque el contenido no cambiara
  • Otra opción es almacenar las imágenes en caché localmente, y la app original parecía usar ese enfoque

Convertir JSON en HTML

• Se escribió un script en Ruby y se configuró para que, siguiendo una programación de Cron, obtuviera el JSON más reciente y generara páginas HTML
• Durante la generación se excluyeron por completo los anuncios inspirations, que correspondían a overlayRows en el esquema de datos
• En la página web solo se mostraba la siguiente información
  1. Elementos del itinerario del viaje
  2. Todos los archivos que no fueran referenciados por anuncios ni por el itinerario
• La segunda lista se aprovechó como una forma simple de reunir en un solo lugar los enlaces de descarga de PDF
• La página generada se protegió con la misma contraseña que se había proporcionado al grupo de viaje existente
• El JSON original se colocó dentro de un elemento <details> para poder detectar si más adelante aparecían datos del esquema que el script todavía no entendía

Una versión web más pequeña y flexible

• La página web no es tan vistosa como la app original, pero es mucho más pequeña y ofrece funciones básicas de la web sin necesidad de implementarlas por separado
• Permite copiar, imprimir, guardar, crear marcadores y buscar contenido, y también se puede acceder desde una mayor variedad de dispositivos
• Al eliminar el código de rastreo y la publicidad, también desaparecen las dos funciones innecesarias que tenía la app original
• No se hizo una auditoría formal de accesibilidad, pero la app original tenía elementos que parecían más difíciles de usar con tecnología de asistencia que una versión web simple

Comparación de tamaño y forma de distribución

• La app original de Travelbound pesa inicialmente 43 MB y, después de descargar contenido adicional, puede crecer hasta 124 MB
• La página web de reemplazo pesa 0.05 MB, y si se descargan todas las imágenes de forma opcional se añaden 35 MB
• Se compartieron ambos enfoques con el grupo de viaje para que cada usuario pudiera elegir si prefería usar la app o la página web
• Para algunas tareas una app puede ser apropiada, pero el contenido de Travelbound, ya escrito en HTML y entregado por HTTP, no es un caso que requiera una app
• Distribuir por app stores aumenta los costos y la carga de desarrollo, y limitar este tipo de contenido documental a una app reduce tanto la cantidad de personas que pueden usarlo como las funciones básicas disponibles, en comparación con publicarlo directamente en la web

[GN⁺]

Opiniones en Lobste.rs

• Estoy harto de que servicios que, en esencia, no son más que páginas web terminen en inflación de apps, así que me alegra saber que no soy el único.
  En Android, crear un acceso directo a una página web no es algo muy visible para el usuario, así que también se entiende por qué las empresas prefieren una app. Aun así, si se trata de un servicio que te manda la contraseña por mensaje junto con un enlace a la app, una web app es lo más adecuado. Basta con enlazar directamente a la página de la contraseña.
  La tienda de apps de /e/OS incluso tiene una sección de “web apps” con entradas como la versión web de Google Maps. Las PWA en sí son fáciles de usar, pero no sé qué tanto el Chrome predeterminado o el Android del fabricante promuevan la creación de accesos directos y la hagan visible.
  Está claro que la forma actual no está pensada para el usuario, y hace falta pensar cómo mejorarla.

• Para el usuario promedio, especialmente para quien no está familiarizado con las computadoras, la diferencia entre una app y una página web en realidad se reduce a un acceso directo en el escritorio o la pantalla de inicio.
  Si se pudieran distribuir accesos directos a páginas web directamente, sería una forma muy barata de desarrollar apps, y probablemente la mayoría de las apps podrían haberse hecho así.

  • En Safari de iOS, si abres una página web y luego eliges “Add to Home Screen” desde el botón de compartir pasando por “View More”, puedes agregar un ícono a la pantalla de inicio.
    Si tocas ese ícono, no se abre una pestaña nueva del navegador, sino una ventana independiente como si fuera una app normal. Yo distribuyo así una herramienta de gastos familiares que hice, sin publicarla en la App Store.

• Muchísimas “apps” podrían ser simplemente páginas web sin problema. Es frustrante que tantas veces haya que instalar una app primero para usar una función mínima sin ninguna buena razón.
  Tiene sentido usar una app para conectarse a un dispositivo local, pero también hay sistemas donde la app termina comunicándose con el dispositivo local pasando por un servidor central. En ese caso, desaparece hasta la única justificación real para tener que instalar una app.
  El iPhone original intentó usar las páginas web como plataforma de apps, pero al final terminamos con el ecosistema desastroso que existe hoy.