4

I am using Firestore for Android. I know it has persistence enabled by default.

Here is some background:

My app shows a list of notes and every note is tied to a label. Therefore while creating a note, I must present a list of labels (in a Dialog, in response to 'Select label' button), which will be provided to me by a snapshot listener on a Query. As creating a note is a separate Activity, each time user goes to create one, the complete list of labels must be presented.

My questions are:

  1. Is snapshot listener smart enough to fetch the data from cache every other time, except for the first time? (And that "first time" will be after 30 mins when the listener expires, or Firestore clears the cache to save space, right?)
  2. What is the impact of attaching and detaching listeners frequently? I am attaching the listener in Activity's onStart() and removing it onStop(). Here, the user may switch between apps to copy data from some other source to add it in the note, making listener detach/attach. Will this impact my read count?
  3. How get() will behave in these scenarios? (I am not a fan of this as it isn't realtime)

Firestore keeps confusing me about the pricing as I dive deep into it. Need a good clarity on the behaviour of components around offline data and its pricing side.

Mangesh
  • 5,491
  • 5
  • 48
  • 71

1 Answers1

3

Is snapshot listener smart enough to fetch the data from cache every other time, except for the first time? (And that "first time" will be after 30 mins when the listener expires, or Firestore clears the cache to save space, right?)

If you are offline, yes, Firestore will get all the data from the cache. This is happening when you are listening to real-time updates. On the other hand, if the real-time updates are not mandatory, you can simply use a get() call and specify the source, as explained in my answer from the following post:

Regarding the cache limit, please check out the following answer:

What is the impact of attaching and detaching listener frequently? I am attaching the listener in Activity's onStart() and removing it onStop(). Here, user may switch between apps to copy data from some other source to add it in the note, making listener detach/attach. Will this impact my read count?

The listeners in Cloud Firestore are cheap, and you should not worry about lots of listeners attached to a document. Attaching and detaching the listeners is the way to go ahead with. It's mandatory to detach the listeners before the activity gets destroyed, as explained in my answer from the following post:

How get() will behave in these scenarios? (I am not a fan of this as it isn't realtime)

When you are using get(), it means that you are getting the data only once. It's the correspondent of addListenerForSingleValueEvent() from Firebase Realtime Database.

Alex Mamo
  • 130,605
  • 17
  • 163
  • 193
  • `if the real-time updates are not mandatory, you can simply use a get()` In this case I will not get any data. Imagine a new user installing the app and I have coded to get data from cache. He will never the receive data. – Mangesh Apr 10 '20 at 10:39
  • *"In this case I will not get any data."* Yes you will, but only once. The option from `CACHE` is used only when you need to force the retrieval of the data from the CACHE and **not** when the user opens the app for the first time. – Alex Mamo Apr 10 '20 at 10:43
  • No, it's not. `get(Source.CACHE)` will never contact the server, it will read the data only from the cache. What exactly do you want to achieve? – Alex Mamo Apr 10 '20 at 11:10
  • What I understood: `1. Is snapshot listener smart enough` - No, it will always prefer server data. `2. impact of detach/attach` - Good coding practice but it will cost reads every time switch happens. `3. get()` - Good for single shot operation. Correct me if I'm wrong. – Mangesh Apr 10 '20 at 11:45
  • 1
    1. No, `get()` will always prefer server data. Passing the source as an argument, this behavior can be changed. 2. It's correct. 3. Correct again. – Alex Mamo Apr 10 '20 at 11:52