FIRESTORE datos persistentes

hablando de datos persistentes de Firerestre, supongamos que el usuario no tiene conectividad la primera vez que se inicia la aplicación. Agregué algunos datos a Firestre Database (como userID ..), puedo recuperarlos con el método get (). Ahora el usuario cierra la aplicación.

  1. La próxima vez que abra la aplicación (aún sin conectividad), ¿podrá recuperar los datos almacenados previamente, como si estuviese almacenada en forma de preferences compartidas? No puedo entender claramente cómo encontrar una forma adecuada de configurar un fase de inicio con datos persistentes.

  2. Tengo varios fragments. Cada vez que se lanza uno de ellos, uso el método "onResume" para completar mis componentes a partir de datos (previamente almacenados en shanetworkingpref). Cuando configuro Firestre getData, lleva time recuperarlo. Entonces, si el usuario cambia del fragment actual a otro, tengo errores sobre los componentes que son nulos o inalcanzables en el momento en que se completa el resultado de la database, cuando la conectividad está activada.

    ¿Cuál sería la mejor manera de implementar el relleno de datos "onResume"?

ACTUALIZAR:

Aquí hay un fragment de código: MainAvtivity .kt

FirebaseFirestre.getInstance().firestreSettings.isPersistenceEnabled sightingsDatabase = FirebaseFirestre.getInstance() docname=FireStoreSetup().setupFB(sightingsDatabase!!,this) 

una class de object kotlin para poblar mi documento:

 data class Sighting(var userID: String, var sig_wit_situation_type: Int, var sig_env_background_type: Int, var sig_ground_type: Int, var sig_YYYY: String, var sig_MM: String, var sig_DD: String, var sig_time_start: String, var sig_date_time: String, var sig_duration_hms: String, var sig_duration_milli: Int, var sig_weather_full: Int, var sig_temp: Int) 

en la class FireStoreSetup : cuando ocurre la primera iniciación ->

 val sighting = Sighting(deviceId!!, 0, 0, 0, strDate.substring(0, 4), strDate.substring(5, 7), strDate.substring(8, 10), strDate.substring(11), strDate, "00:00:00", 0, 0, 0) db.collection("users").document(docname!!) .set(sighting) .addOnSuccessListener { Log.d(_tag, "DocumentSnapshot successfully written!") setShanetworking(context,"doc_name",docname!!)} .addOnFailureListener { e -> Log.w(_tag, "Error writing document", e) } 

entonces una diversión para escribir datos en el server

 fun addValue(key:String,value:Any?){ val docData = HashMap<String,Any?>() docData.put(key, value) FirebaseFirestre.getInstance().collection("users").document(docname!!) .set(docData, SetOptions.merge()) } 

y

  fun readValue(){ val docRef = FirebaseFirestre.getInstance().collection("users").document(docname!!) docRef.addSnapshotListener(object:EventListener<DocumentSnapshot> { override fun onEvent(snapshot:DocumentSnapshot?, e:FirebaseFirestreException?) { if (e != null) { Log.w("firestre", "Listen failed.", e) } if (snapshot != null && snapshot.exists()) { Log.d("firestre", "Current data: " + snapshot.getData()) FragmentHome.vars=snapshot.getData() } else { Log.d("firestre", "Current data: null") } } }) } 

en FragmentHome :

 companion object { val itemsMenu = ArrayList<MenuData>() var vars: MutableMap<String,Any>? =null fun newInstance(value: Int): FragmentHome { val args = Bundle() args.putInt("menu", value) val fragment = FragmentHome() fragment.arguments = args return fragment } } override fun onResume() { super.onResume() FireStoreSetup().readValue() when (_menu){ 0-> switchRecycler(1,0) 1-> switchRecycler(0,0) } } 

y luego desde fragmentHome, reemplazándolo con un nuevo fragment con valores Firerestre:

 val situ= vars!!["sig_wit_situation_type"].toString().toInt() val env= vars!!["sig_env_background_type"].toString().toInt() val grd= vars!!["sig_ground_type"].toString().toInt() reFrag(FragmentSitu.newInstance(situ,env,grd), 1) 

donde en el nuevo fragment FragmentSitu tenemos:

 companion object { fun newInstance(situ: Int,env: Int,grd: Int): FragmentSitu { val args = Bundle() args.putInt("sig_wit_situation_type", situ) args.putInt("sig_env_background_type", env) args.putInt("sig_ground_type", grd) val fragment = FragmentSitu() fragment.arguments = args return fragment } } 

y funciona sin retrasos, en línea y fuera de línea, gracias a Franck y docRef.addSnapshotListener.

** Debe haber una forma mejor de capturar el resultado de snapshot.getData() desde dentro de onEvent(snapshot:DocumentSnapshot?) , Ya que me hubiera gustado establecer mi fragment args FragmentSitu.newInstance (situ, env, grd) directamente desde snapshot.getData()["situ"] , snapshot.getData()["env"]

Como dice la documentation oficial ,

Cloud Firestre admite la persistencia de datos sin connection. Esta function almacena en la memory caching una copy de los datos de Cloud Firestre que su aplicación utiliza de manera activa, por lo que su aplicación puede acceder a los datos cuando el dispositivo está fuera de línea.

Pero para usar esta function, necesita al less una connection a la database. Esto significa que su aplicación debe estar conectada a Internet al less una vez. Después de eso, podrá escribir, leer, escuchar y consultar los datos en caching.

Si desea utilizar datos entre actividades o fragments, lo recomiendo usando Intent o ShanetworkingPreferences , que pueden contener sus datos en toda la aplicación.

firebaser aquí

Firestre mantiene los datos que escribe en un dispositivo en una database local. Por lo tanto, la próxima vez que inicie la aplicación, podrá leer los mismos datos, incluso cuando el dispositivo nunca se haya conectado a los serveres de Firebase.

Cuando la aplicación intenta leer datos de Firestre por primera vez, intenta establecer una connection con sus serveres. Si usa las llamadas get() para leer los datos, Firestre esperará a que se establezca o falle esa connection antes de que regrese los datos. Esto significa que puede tomar bastante time para esta llamada inicial. Sabemos que esto puede provocar un comportamiento no deseado para los usuarios de su aplicación, por lo que estamos buscando forms de mejorar este comportamiento.

Mientras tanto, considere usar oyentes en time real para leer los mismos datos. Estos oyentes se comportan de manera diferente en este escenario y pueden / pueden proporcionar un resultado dos veces:

  1. La primera instantánea se da de inmediato y proviene de la memory caching local.
  2. La segunda instantánea se da luego, una vez que el cliente ha recibido una respuesta de la database de la nube.