0

In my use case, the data is only written by client, not by server.

But I would like to use Cloud Functions on the server, whenever a change is made on the client.

What I would like to avoid is to re-download the data from the server if it's already locally stored.

I found out is it possible to enable disk persistance: FirebaseDatabase.getInstance().setPersistenceEnabled(true);

Can anyone explain if this actually prevents re-downloading data in case it's already locally stored, or the data would periodically re-downloaded anyway?

Generally speaking, which is the criteria by which the data is re-downloaded? Is there a sort of hashcode check between client and server data to find out if the data has changed?

Daniele B
  • 19,801
  • 29
  • 115
  • 173

1 Answers1

1

Calling setPersistenceEnabled(true) enabled Firebase's disk cache. It's primary purpose is to ensure your app continues to work when there is no network connection. In addition it may reduce data transfer, but that depends on quite a few variables.

For some more information on what disk persistence means, how it interacts with Firebase's in-memory caching of data, and more, see:

Frank van Puffelen
  • 565,676
  • 79
  • 828
  • 807
  • Thanks Frank. So, in case I use both: `FirebaseDatabase.getInstance().setPersistenceEnabled(true);` and `ref.addValueEventListener(listener);` and the server never changes the data, can I expect no data will be re-downloaded from the server? – Daniele B Aug 03 '17 at 21:09
  • It's not that simple unfortunately. There will be traffic with the server to check whether the data is up to date. This is "just a bunch of hashes". But it can add up depending on the data you store. Unfortunately not a simple answer. – Frank van Puffelen Aug 03 '17 at 22:56
  • Would that traffic you are talking about be completely excluded in case the `ref.addListenerForSingleValueEvent(listener);` listener is used instead? – Daniele B Aug 03 '17 at 23:00
  • No it wouldn't. See "What happens when you use addListenerForSingleValueEvent" in the third link I shared above. – Frank van Puffelen Aug 03 '17 at 23:05
  • According to what it's written there, the data won't be fetched from the server: `The Firebase client will (like in the previous situation) immediately invoke onDataChange() for the value from the local disk cache. It will not invoke the onDataChange() any more times, even if the value on the server turns out to be different.` – Daniele B Aug 03 '17 at 23:09
  • "f the value of the location is in the local disk cache, the Firebase client will invoke `onDataChange()` immediately for that value from the local cache. **It will then also initiate a check with the server, to ask for any updates to the value**. It may subsequently invoke `onDataChange()` again if there has been a change of the data on the server since it was last added to the cache." – Frank van Puffelen Aug 04 '17 at 00:48
  • What you quoted refers to `addValueEventListener`, not to `addListenerForSingleValueEvent` – Daniele B Aug 04 '17 at 00:51
  • It doesn't, it refers to any listener you attach. The two methods do the exact same thing. The only difference is that `addListenerForSingleValueEvent()` immediately removes the listener after it fires the first `onDataChange()`. I'll update my linked answer to clarify this. – Frank van Puffelen Aug 04 '17 at 01:00
  • Frank, if the listener is removed after the first callback, I assume there won't be any more data retrieved from the server. Isn't it true? – Daniele B Aug 04 '17 at 01:18
  • Correct. But a check will be initiated once, even when the value is already in the cache. Given the level of detail that you seem interested in, you may be better helped by [enabling debug logging](https://firebase.google.com/docs/reference/android/com/google/firebase/database/FirebaseDatabase.html#setLogLevel(com.google.firebase.database.Logger.Level)) and checking the wire traffic in the logcat output. – Frank van Puffelen Aug 04 '17 at 01:34