Admite varias versiones de aplicaciones móviles

7

Estamos creando un conjunto de aplicaciones móviles nativas para complementar nuestra aplicación existente que actualmente solo admite una interfaz web para el servidor. La aplicación puede ser instalada y hospedada por los clientes en su propia infraestructura o puede ser hospedada por nosotros mismos para los clientes que quieran hacer uso de ella. Por lo general, los clientes de grandes empresas optan por auto hospedarse, mientras que los clientes más pequeños eligen nuestra opción de alojamiento.

Necesitamos soportar múltiples versiones de la aplicación. No todos los clientes quieren actualizar al mismo tiempo. Con la interfaz web, no es difícil admitir varias versiones, ya que la interfaz web utiliza automáticamente la versión del servidor asociada a su instalación. Con las aplicaciones móviles donde normalmente solo tiene una aplicación disponible en las tiendas de aplicaciones, el soporte para diferentes niveles de la API del servidor y la funcionalidad de la aplicación móvil se convierten en un desafío. Me interesa saber cómo otras personas están resolviendo el problema. En mi opinión, tienes opciones como:

  1. Admite varias versiones de la aplicación en la tienda de aplicaciones.
  2. Cree soporte en las aplicaciones móviles para determinar automáticamente la versión de la API del servidor al que está hablando y enrutar las llamadas a los puntos finales de la API del servidor correspondiente. También introduzca el uso de algún tipo de mecanismo de activación de funciones para habilitar / deshabilitar la funcionalidad en la aplicación móvil según lo que esté disponible en las diferentes versiones del servidor.
  3. No use la tienda de aplicaciones para implementar su aplicación. Señala a los usuarios una URL específica de la versión que pueden usar para descargar e instalar la aplicación.

Opción 1 : IMO creará confusión para los usuarios de la aplicación. Tampoco hay una ruta de migración agradable de una versión de la aplicación a la siguiente, ya que realmente son dos aplicaciones separadas.

Opción 2 : por otro lado, puede volverse muy complejo rápidamente si se tiene en cuenta que las imágenes de UI ahora básicamente necesitan adaptarse a cualquier funcionalidad disponible en la versión de la API del servidor. Hablando a. También debe admitir las diferentes versiones de las llamadas a la API del servidor que debe realizar.

Opción 3 : es posible en el mundo de Android al realizar una carga lateral de tu aplicación, pero por lo que sé, no es compatible con iOS y no estoy seguro de cuál será la imagen para Las aplicaciones móviles de Windows 10 avanzan.

¿Qué otros enfoques existen para abordar el problema? Por favor, no discuta el hecho de que estamos escribiendo aplicaciones nativas. Eso no es lo que estoy preguntando. Estoy buscando orientación sobre cómo otras personas están abordando el problema de admitir múltiples versiones de la misma aplicación móvil nativa al hablar con diferentes versiones de una API de servidor.

    
pregunta Carel 24.08.2015 - 06:43

3 respuestas

2

Mira lo que pasará ...

La opción 1 generará llamadas de soporte cuando los usuarios instalen la versión incorrecta. Siempre habrá un usuario que no puede leer o elegir la versión más reciente pensando que sabe mejor ... y tendrá una gran cantidad de versiones para las posibles soluciones de backport si lo necesita.

La opción 2 agrega algo de complejidad al código de la interfaz de usuario, cuánto depende de qué tan bien la interfaz de usuario está escrita para ser adaptable. Pero tiene la mejor experiencia de usuario.

La opción 3 no puede ocurrir en iOS (Android y Windows lo permitirán en ciertas configuraciones), lo que significa diferentes comportamientos para diferentes plataformas. Eso hace que las cosas sean inconsistentes, lo que es una receta para los problemas.

Por lo tanto, fuera de eso, crear una IU receptiva y apuntar al punto final correcto es, con mucho, la mejor manera de ir para sus usuarios.

    
respondido por el James Snell 28.08.2015 - 23:14
1

He lidiado con esto en un contexto ligeramente diferente, pero se nos ocurrió que si utilizabas nuestro servidor público te pedíamos que lo actualizaras. Si usted se hospedó, le permitimos permanecer en cualquier versión que le gustara.

Sé que no es la respuesta más amigable para el cliente, y podría no ser una opción dependiendo de su situación, pero fue la postura que terminamos tomando.

Una cosa a tener en cuenta: terminamos teniendo que hacer un montón de operaciones puntuales basadas en las líneas de base antiguas que se alojaban por cuenta propia cuando encontramos problemas de seguridad o errores importantes. Si admite múltiples versiones, ya sea de la forma en que lo hicimos o si termina por soportar múltiples API por completo, debe asegurarse de tener una administración de configuración y un control de fuente sólidos. A medida que encuentre errores, asegúrese de tomarse el tiempo para buscarlos en su origen, ya que es posible que tenga que corregirlos en una rama antigua.

    
respondido por el GMLewisII 28.08.2015 - 21:41
0

El control de versiones de la API está bien, pero esto requeriría más trabajo en la capa de interfaz de usuario a) La interfaz de usuario debe saber qué versión de la API debe invocarse según la configuración (use un archivo de propiedades o un archivo de recursos en el dispositivo cliente)

b) También el servidor debe tener soporte para varias versiones de las API.

¿La API del servidor solo atiende a clientes móviles o también tiene otros clientes? Si se dirige a otros clientes, entonces solo para Mobile, es posible que desee obtener una API de envoltorio que básicamente llame a la API del servidor en un extremo con soporte de control de versiones.

Básicamente, la creación de versiones es difícil en la API del servidor si hay otros clientes como las API públicas que son atendidas por la API del servidor, de lo contrario es simple

Mis 2 centavos.

    
respondido por el Chandra 24.08.2015 - 20:01

Lea otras preguntas en las etiquetas