1

Let's say the app performs a simple read operation on the RTDB, maybe something like this:

Firebase.database.reference.child("foo").addListenerForSingleValueEvent (object: ValueEventListener {
    override fun onCancelled(p0: DatabaseError) = Unit
    override onDataChange(snap: DataSnapshot) {
        //....
    }
})

Let's say the connection has not been established, maybe because the user is not connected to the Internet, to begin with, or they lost the connection, and a read is initiated from a Fragment, so unless the user reconnects to the Internet and the read succeeds or they restart the app and the read request is removed (in the case where offline persistence is disabled), the read request will remain and the app will try to connect to the Firebase RTDB to fetch the data.

So my question here is, is there a way to "cancel" a read request after a certain amount of time passes, maybe by using the delay coroutine and after a certain delay period, "canceling" the read request, and initiating it again only after notifying the user to check their connection or something similar.

Alex Mamo
  • 130,605
  • 17
  • 163
  • 193
Yash Singh
  • 57
  • 6
  • So you say that if the user is offline, and if the user for a limited period of time doesn't regain connection, you don't want to read something at all? – Alex Mamo Sep 08 '20 at 08:03
  • As far as I understand, Firebase uses exponential back-off-and-retry when it can't connect to the database, so in the case that the user is offline, and a certain amount of time has passed, I want to be able to definitively cancel the read request because let's say the user realised they are not connected and reconnects , but due to how Firebase works it might take some time before the data is fetched and they see any result, causing a poor experience. So to avoid this, after a delay, I would want the app to cancel the request and initiate it only after the user has been sufficiently informed. – Yash Singh Sep 08 '20 at 08:35
  • But what do you mean through "cancel" the read? You want to stop getting data from Firebase? – Alex Mamo Sep 08 '20 at 08:51
  • Okay, I had written out a long explanation but I realised something and I would just ask you to consider if this would work as intended. So after a certain time has passed since attaching the `ValueEventListener` using `addListenerForSingleValueEvent()` , and the value hasn't been fetched yet, if `removeEventListener()` is used, then would the value not be fetched, and the piece of code inside `onDataChange()` wouldn't get triggered ? – Yash Singh Sep 08 '20 at 09:12
  • I'll write you an answer regarding your last comment right away. – Alex Mamo Sep 08 '20 at 09:16

1 Answers1

1

So after a certain time has passed since attaching the ValueEventListener using addListenerForSingleValueEvent() , and the value hasn't been fetched yet, if removeEventListener() is used

First of all, when you are using addListenerForSingleValueEvent(), it means that you are getting the data exactly once, case in which there is no listener that needs to be removed. However when using addValueEventListener(), it means that you are listening for changes in real-time, case in which you need to remove the listener accordingly to the life-cycle of your activity.

So if you need that behavior, you can remove the listener after a period of time, meaning that you'll stop listening for changes. In this case, not data will be fetched. If you need later to get the data, simply attach the listener again and start listening for changes.

There is also a library that you might be interested in, which is called Firebase-UI. This library can help you manage that kind of situation more easily.

Alex Mamo
  • 130,605
  • 17
  • 163
  • 193
  • Aah, I had missed the fact that `addValueEventListener()` could be used to attach a listener and remove it if I don't want the data to be fetched. Also, I believe, if I want to emulate the behaviour of `addListenerForSingleValueEvent()`, I could just call `removeEventListener(this)` inside the former function once it has been triggered, while also availing the benefit of a removable listener, giving me the option to "cancel" the read request. Finally, thanks so much for taking the time to bear with my question. – Yash Singh Sep 08 '20 at 17:12