0

When I start listening for the onDataChange() event the handler receives a value. This value is the one previously saved locally. Then it immediately calls the handler a second time and retrieves the correct updated value on the cloud.

The documentation says:

You can use the function to read a static snapshot of the contents at a given path, as they existed at the time of the event. This method is triggered once when the listener is attached and again every time the data, including children, changes.

I read "as they existed at the time of the event", not as it existed LOCALLY at the time of the event.

I expect the method to trigger once when is added retrieving the real-time value and not the one saved locally, and then to trigger every time the value is changed.

How to reproduce:

  1. Load an existing object via:

    onDataChange(DataSnapshot dataSnapshot)... // value = "Hello world"

  2. Kill the App and change the value via Firebase console to "Hello again World";

  3. Load again the object via:

    onDataChange(DataSnapshot dataSnapshot)... // value = "Hello world"

  4. Wait and the handler will be called again immediately after with the value: "Hello again World"

I don't know if this is a bug or if it's by design.

In case this is the default behavior and is by design, is there a way for me to know if the value is the last saved local value?

Frank van Puffelen
  • 565,676
  • 79
  • 828
  • 807
GV3
  • 491
  • 3
  • 16

1 Answers1

1

When you listen for a value that exists in the persistent cache, the Firebase client will immediately fire an event with that local value. It will then synchronize with the server. If this results in an updated value, the client will fire a second value event.

There is currently no way to know whether the event came from the server or from the local cache. It is best if you design your code to cater for all cases.

Frank van Puffelen
  • 565,676
  • 79
  • 828
  • 807
  • Wow, I'm surprised and not in a positive way. Thank you very much for the clarification. Do you know if there is any plan to inform the developer about the origin of the data? Or somewhere where I can vote for that feature? – GV3 Sep 12 '16 at 09:32
  • 1
    We're aware that not being able to see where data comes from limits the use-cases of our persistence feature. It is unfortunately not something we can easily change within our current API without breaking existing clients. But we're looking to improve this in the future. As usual though: no promises and no timelines. For the moment, it is recommended that you design your app to cater for this behavior. – Frank van Puffelen Sep 12 '16 at 15:29