Mi experiencia de migrar CookiesStorage de SharedPreferences a DataStore en Android como parte del proyecto KMM | de Sergei Mijailovski | noviembre 2022

La imagen está tomada de dreamstime.comIntroducciónPrimero, expliquemos por qué necesito CookiesStorage. Para identificar al usuario, el servidor coloca tokens JWT en las cookies. Y todas las solicitudes de la aplicación móvil deben enviarse con esta cookie. Cuando los usuarios cierran sesión en la aplicación, la cookie de token se elimina cuando finaliza la sesión. Ahora expliquemos cómo se implementó el CookiesStorage anterior. Dado que el proyecto tiene módulos KMM (actualmente solo se admite la parte de Android), uso la biblioteca Ktor para la malla. Nos permite instalar el complemento HttpCookies. Lo que se refiere a CookiesStorage es la subclase de CookiesStorage de Ktor (io.ktor.client.plugins.cookies.CookiesStorage). Así es como lo implementé. Como puede ver, la lógica es bastante simple. Cuando el servidor establece la cookie, el sistema verifica si esta cookie es compatible con la aplicación (presente en CookieType), la almacenamos en el almacenamiento local (si el valor de Android se almacena en SharedPreferences). Y aquí nos encontramos con el principal problema. Dado que SharedPreferences solo se admite en Android, debemos usar el mecanismo Expect-Actual de KMM y escribir implementaciones en iOS y Android. Pero recientemente, el equipo de Android anunció la versión KMM de DataStore. Para mi caso es una bala de plata ya que me permite:

1. Migrar de SharedPreferences a DataStore (puede leer sobre sus beneficios en este brillante artículo)
2. Tener el mismo código multiplataforma en lugar de clases reales esperadas

Actualmente, el mayor inconveniente es que la biblioteca está en desarrollo, pero ¿cuándo los desarrolladores la detuvieron? Ahora déjame explicarte cómo migré a DataStore.punto unoNecesitamos agregar las dependencias: androidx.datastore:datastore-preferences-core:1.1.0-dev01 (en la parte compartida) y androidx.datastore:datastore-preferences:1.1.0-alpha01 (ya que contiene SharedPreferencesMigration). discutido después). Tenga en cuenta que las versiones son diferentes.punto dosCreé un repositorio separado para DataStore. Aquí está el listado ¿Qué tenemos aquí?

• En primer lugar, ahora el repositorio está en el módulo común en lugar de las partes de Android e iOS. La clase DataStoreRepository implementa DataStoreRepository desde la capa de dominio para lograr el principio de inversión de dependencia y probar fácilmente la clase.
• Segundo: en lugar de di container (que necesitamos para obtener SharedPreferences), ahora pasamos DataStore directo. Así que conceptualmente nada cambia.
• Tercero: los métodos para recuperar y almacenar valores se han suspendido ya que se suspendió la edición de DataStore (en el caso de valores de lectura). ¿Qué pasa con la lectura de los valores? Elegí no devolver Flow porque en la implementación actual ejecuto el método en cada solicitud, por lo que no necesito el mecanismo de observación. Es suficiente usar firstOrNull, pero como también está suspendido, el método getString ha sido suspendido.

Recuperar el valor de PreferencesDataStore es muy similar a trabajar con preferencias compartidas, pero en lugar de los métodos getString, getInt, etc., ahora usamos PreferencesKeys (puede encontrar una lista completa aquí). Y CookiesStorage casi no ha cambiado. La única diferencia es que ahora paso DataStoreRepository en lugar de PreferencesRepository. Pero probablemente sean las mismas entidades.Casi el último…Y aquí nos enfrentamos a un pequeño problema: cómo migrar los datos ya almacenados en SharedPreferences a DataStore. Por suerte es fácil. Cuando creamos la instancia del DataStore podemos pasar la lista de migraciones (recuerda que solo debes tener una instancia del DataStore en el mismo proceso para evitar acceder al archivo al mismo tiempo y atrapar la excepción). Primero: así es como se ve la creación de DataStore: Segundo: así es como creo la lista de migración: dentro de SharedPreferencesMigration, necesitamos pasar el objeto SharedPreferences o el contexto y el nombre de la configuración, para que la función pueda obtener el objeto SharedPreferences bajo el capó Además, podemos especificar las claves que queremos migrar como tercer parámetro. Debajo del capó, la función de migración parece simple, solo leemos todos los valores de SharedPreferences, luego filtramos solo los valores que necesitamos y los almacenamos en Preferencias.Conclusión.

1. La aparición de este DataStore en KMM es otro punto a considerar en el lado de KMM para los desarrolladores de Android, ya que nos permite usar clases y métodos más familiares en todas las plataformas. Sin embargo, tenga en cuenta que la biblioteca está en la versión para desarrolladores.
2. Nos permite usar código más común en lugar de expect/actual.
3. Con la ayuda del flujo podemos observar los cambios de la memoria.
4. Para situaciones más complejas (que los valores clave persistentes), puede usar ProtoDataStore (los enlaces están aquí y aquí).
5. DataStore es una alternativa más potente a la biblioteca de configuración.
6. Tiene el mecanismo de migración.

Puedes encontrar el código fuente en Github. ¡Gracias por leer! No dude en hacer preguntas y dejar sus comentarios en los comentarios o en Linkedin.