Compatibilidad con versiones anteriores: Cómo no romper su aplicación en el futuro | Autor: Nick Confree | Agosto de 2021
Los usuarios no actualizarán sus aplicaciones, por lo que debe estar preparado desde la primera línea de código. La compatibilidad con versiones anteriores es una de las cosas más difíciles de hacer correctamente en el desarrollo de aplicaciones. Requiere que piense en el futuro y considere todo el desarrollo de funciones posibles. He propuesto algunas reglas que pueden hacer que todo el proceso sea menos abrumador.
¿Qué es la compatibilidad con versiones anteriores?
La compatibilidad con versiones anteriores es un conceptonorte Cualquier versión de la aplicación se puede ejecutar en el futuro, incluso si la respuesta de datos se ha actualizado. Imagina que estás creando una aplicación para compartir fotos que muestra imágenes en un feed. Después de unos meses, decides agregar el video al feed. Funciona bien en la última versión de la tienda de aplicaciones, pero ¿qué pasa con los usuarios que no han actualizado sus aplicaciones? En el peor de los casos, el feed se bloqueará debido a tipos de datos inesperados del servidor. Los nuevos datos del cliente antiguo son la cuestión fundamental para garantizar la compatibilidad con versiones anteriores.
Hay dos problemas principales de compatibilidad con versiones anteriores: colapso, con Datos inconsistentes.
En el caso de los accidentes, suelen deberse a alguna de las siguientes razones Cambiar el tipo de datos esperado, o Eliminar el tipo de datos esperadoPor ejemplo, al cambiar el tipo esperado al analizar la respuesta del feed, es fácil provocar accidentalmente que el análisis JSON se bloquee. De manera similar, cuando se elimina un campo de la carga útil del servidor, se puede violar la garantía de nulabilidad del cliente anterior, lo que da como resultado una falla de referencia nula. Agregar nuevos campos rara vez causa un bloqueo, porque los clientes antiguos no accederán a estos puntos finales.
Para las inconsistencias de datos, los usuarios pueden perder funciones clave y no saber qué se perdieron. Volviendo al ejemplo de la transmisión de imágenes / videos nuevamente, si el cliente anterior no sabe cómo presentar el video en la transmisión, el usuario se perderá la mitad del contenido de su aplicación. Otros problemas incluyen violaciones de privacidad, donde los clientes más antiguos no respetan la configuración de privacidad de la aplicación más nueva (por ejemplo, usuarios bloqueados, contenido privado).Si diseña una API y agrega un campo a la foto, dice isPrivate
, Los clientes antiguos no saben que la imagen no se muestra. Al agregar nuevas funciones de servidor, es fundamental considerar cuidadosamente el comportamiento del cliente anterior.
Por supuesto, cuando encuentra problemas de compatibilidad con versiones anteriores, el mayor dolor viene, porque para entonces será demasiado tarde para solucionarlo.
Vale la pena señalar que la compatibilidad con versiones anteriores es solo una cuestión de aplicaciones que requieren una respuesta del servidor. Si está construyendo una aplicación fuera de línea para un solo jugador, entonces está fuera de la situación: no habrá inconsistencias entre las versiones de la aplicación. Los usuarios pueden actualizar la versión de trabajo desde la tienda de aplicaciones en cualquier momento.
¿Por qué es importante la compatibilidad con versiones anteriores?
Los usuarios no actualizarán sus aplicaciones como nos gustaría que fueran desarrolladores. Por lo tanto, es posible que tenga una gran cantidad de usuarios en la versión anterior. Tener en cuenta la compatibilidad con versiones anteriores de la primera línea de código puede evitar todos los posibles bloqueos e incoherencias de datos.
Afortunadamente, para tener éxito en el futuro, seguí algunas estrategias en mi aplicación. Esta recomendación se aplica a iOS y Android, y debe implementarse sin importar cómo construya el backend.
Paso 1: construye una escotilla de escape
Comenzando desde el peor de los casos, si algo sale mal catastróficamente, necesitará una forma de obligar a los usuarios a actualizar. La mayoría de las veces, hará un modo de pantalla completa y bloqueará la interacción con la aplicación hasta que el usuario se actualice.
Para lograr esto desde el principio del ciclo de vida de la aplicación, recomiendo crear una consulta «Noticias del día», que es lo primero que se ejecuta cuando se abre la aplicación. Allí, puede agregar una bandera, lo que hará que la aplicación deba actualizarse. También debe tener una arquitectura de agente de usuario definida que se utilice para pasar la versión de la aplicación y otra información de diagnóstico útil en cada carga del servidor.
Nota: asegúrese de utilizar esta opción con precaución. Cada vez que bloquea la funcionalidad de una aplicación para una actualización, puede perder muchos usuarios. En su lugar, continúe realizando estos pasos para manejar los errores de manera más elegante y permitir que los usuarios con versiones anteriores de la aplicación continúen trabajando.
Paso 2: implementar marcadores de posición de contenido
Para cada contenido de la aplicación, debe haber una forma de eliminarlo y pedirle al usuario que actualice su aplicación.Esto también te obliga a considerar default
Es posible que esté realizando cualquier situación de cambio de respuesta del servidor para evitar bloqueos.
En una aplicación con una fuente, cada contenido de la lista de respuestas del servidor se analiza en un tipo de datos que acepta valores NULL. Luego, puede diseñar un bloque de contenido simple, cuando los datos finalmente estén vacíos, tal vez una simple opacidad UILabel:
let updateAppLabel: UILabel =
let label = UILabel()
label.text = "Update your app to see this content!"
label.backgroundColor = UIColor.black.withAlpha(0.8)
()
Al igual que con cualquier respuesta de servidor, es importante considerar siempre el caso nulo, tanto para fallas de red reales como para datos nuevos inesperados de servidores futuros.
Paso 3: escriba un código de servidor serio
Hasta ahora, me he centrado en extinguir incendios: asegurarme de que nuestra aplicación cliente no cometa errores cuando lanzamos accidentalmente nuevas funciones en el servidor. Pero para la categoría de inconsistencia de datos, depende del servidor escribir una nueva API que tenga en cuenta la versión anterior del cliente.
Aquí hay algunas suposiciones falsas que me encontré haciendo:
- No asuma que el cliente respetará el logo. En su lugar, aplique el filtrado de contenido del lado del servidor.
- No asuma que el cliente llamará a una nueva consulta. Esto es especialmente perjudicial para el procesamiento del lado del servidor; por ejemplo, si la carga se realiza correctamente, deje que el cliente obtenga nuevas imágenes de su nuevo motor de filtrado de fotos favorito. Una vez que se completa el procesamiento del lado del servidor, el cliente anterior no se dará cuenta de la devolución de llamada.
- No elimine los campos no utilizados. Desafortunadamente, para la compatibilidad con versiones anteriores, debe mantener estos puntos finales para que los clientes antiguos se conecten y llamen.
Siga estos pasos para evitar grandes dolores de cabeza en el futuro; después de todo, no puede cambiar el pasado.