android - uso - Móvil: ¿la aplicación móvil hace una contra dos solicitudes paralelas?

instalar la misma aplicacion dos veces android

Question

Usamos GooglePlaces en nuestra aplicación móvil Android / iPhone para descargar tiendas cercanas. Además, tenemos tiendas en nuestra base de datos que queremos mostrarle al usuario.

En este momento, tan pronto como nuestra aplicación móvil tiene una posición, se activan dos solicitudes HTTP, una para Google Places y otra para nuestro servidor. Tan pronto como finalicen ambos requets, la aplicación construye una lista combinada y se lo muestra al usuario. Estamos hablando de un total de 50 Kb en ambas solicitudes.

Estamos pensando en solo hacer una solicitud a nuestro servidor. Nuestro propio servidor luego haría la solicitud a Google Places, combina las dos listas y envía ambas de vuelta al cliente móvil. La ventaja sería que nuestra aplicación móvil solo necesita lanzar una solicitud, pero puede haber una latencia adicional cuando nuestro servidor se conecta a googleplaces.

La prueba de la segunda opción demoraría todo un día para nosotros. ¿Alguien más se ha encontrado con un problema similar? ¿Qué recomendarías?

Answer 1

Es una solución de compromiso, pero tuvimos problemas similares: nuestra aplicación realizó solicitudes independientes (no a googleplaces, sino a otras API) y finalmente convertimos a un solo modelo de solicitud. Las ventajas para nosotros fueron más allá de reducir el número de solicitudes de aplicaciones.

1. El factor más importante que nos hizo cambiar fue que la API que utilizábamos implementó un cambio con un tiempo de notificación relativamente corto. Esto requirió que realizáramos los cambios en el código y volviéramos a implementar la aplicación. Aún así, hubo algunos que no se actualizaron y enviaron solicitudes de soporte preguntándose por qué la aplicación dejó de funcionar como estaba previsto. En el modelo de solicitud única, podemos evitar estas actualizaciones (y problemas de soporte asociados). Cuando el proveedor de datos ascendente cambia en la API, manejamos la conversión a nuestro formato interno en el servidor.
2. En relación con 1) hemos podido incorporar fuentes de datos adicionales sin actualizar la aplicación. A medida que localizamos nuevas fuentes de datos que se adaptan a nuestro modelo existente, podemos implementarlos sin una actualización de la aplicación.

3. Podemos almacenar algunas de nuestras solicitudes en el servidor. Sus solicitudes pueden ser demasiado locales y debe verificar si las TOS permiten el almacenamiento en caché, pero para nosotros, hemos podido mitigar parte de la latencia con los resultados del almacenamiento en caché. También nos ha permitido degradar elegantemente durante un corte de API.

4. Pudimos optimizar los datos antes de enviarlos al dispositivo. Filtramos cualquier elemento de datos que sabemos que la aplicación no utiliza en el servidor y optimizamos el xml para que el tamaño de descarga disminuya en un 20% -30%.