Android solicita Pt. 1: Try-Catch Navigation, setFragmentResultListener y control de versiones SharedPreferences | por yggr | julio de 2021
Aquí hay algunos consejos sencillos que me gusta hacer al desarrollar aplicaciones de Android. Las soluciones proporcionadas aquí no son de ninguna manera soluciones claras al problema, solo son adecuadas para mis necesidades. En otras palabras, espero que estas soluciones también le resulten útiles.
problema
Cuando usa los componentes de navegación de Android Jetpack y SafeArgs, generalmente usa la clase de dirección generada para navegar entre fragmentos. Por ejemplo, suponga que tiene dos fragmentos: FirstFragment con SecondFragmentPor lo general, esta es la forma de navegar de la primera a la segunda:
problema Como he experimentado muchas veces en el pasado, cuando su aplicación se retrasa y el usuario activa navigate Características Mas de una vez Causa este error:
navigate La función se llama dos veces (cuando el usuario ya está SecondFragment)solución
La solución es simple: solo use la función de navegación Un bloque de intentar atrapar. Esta solución funcionó para mí porque sabemos exactamente qué causó el problema ( navigate La función se llama dos veces), podemos ignorar con seguridad las excepciones lanzadas por la biblioteca. Esto es lo que parece:
Para hacer las cosas más convenientes, puede crear una clase auxiliar simple que contenga el siguiente código:
problema
setFragmentResultListener Es una forma conveniente de transferir datos entre fragmentos.Por lo general, solo necesita llamar a esta función una vez en su Fragmento onCreate Métodos como este:
Pero encuentro que a veces si cambias entre muchos clips, es posible setFragmentResultListenerde No se llamará la devolución de llamada Por alguna razón desconocida.
solución
No estoy seguro de que esta sea la solución ideal, pero descubrí que solo llame setFragmentResultListener No es suficiente.tú también Debe llamar clearFragmentResultListener. Estas funciones deben estar en onResume con onPause Métodos, respectivamente.
Para mayor comodidad, podemos empaquetar esta solución en un componente consciente del ciclo de vida de la siguiente manera:
De esta manera, la configuración y el procesamiento del oyente se encapsularán en una clase. Para usar esta clase, simplemente observe esta clase de su Fragmento de esta manera:
problema
SharedPreferences proporciona un mecanismo integrado simple para almacenar datos de valor clave en su aplicación de Android. Pero en su simplicidad, existe un problema que puede ser fatal para su aplicación.El problema es Su tipo.
En el pasado, almacené algunos valores en SharedPreferences.Llamemos a este valor user_id. por mucho tiempo, user_id Siempre un número entero.Pero cuando se lanzó la nueva versión, decidimos cambiar user_id De entero a cadena. Adivina qué pasará después de que lancemos la nueva versión:
Usuarios antiguos guardados antes user_id Como un número entero pasará Error de transmisión Cuando su aplicación intenta recuperar el valor.
solución
Por supuesto, la solución más obvia y sencilla es getString o getInt Función con bloque try-catch. Pero encontré otro método, que es más simple que usar bloques try-catch y requiere menos trabajo.Esto esta usando control de versiones.
Esto es lo que llamo control de versiones:
Como puede ver arriba, simplemente agregamos una versión a la clave SharedPreferences que estamos usando.Entonces, el anterior user_id Será cambiado a user_id_1. Con esta modificación, si desea cambiar el tipo user_id Solo necesitas aumentar SP_VERSION Value, y su aplicación no se bloqueará para los usuarios antiguos que todavía usan la versión anterior de SharedPreferences.
Captura
- Este método asume que la aplicación pierde por completo todos los valores de SharedPreferences anteriores almacenados en la aplicación.Por ejemplo, cuando desde
user_id_1auser_id_2, Ya no podremos accederuser_id_1. - Puede duplicar este método
SP_VERSION = BuildConfig.VERSION_CODE 🤔
¡Es todo por hoy! ¡gracias por leer! !
