job.answiz.com
  • 1
Votes
name

I have a query to be made for once and don't want to keep a listener, so that the data updates when a manual trigger is sent.

So my query goes like this :

var ref = this.instance.child('/user/manish/today/events')
    .orderByChild('endDateTime')
    .endAt(endEventTime)
    .limitToLast(10)
    .addListenerForSingleValueEvent(this.previousEventListeners);


  this.previousEventListeners = new com.google.firebase.database.ValueEventListener({
      onDataChange: (snapshot) => {
        console.log("Value from native firebase access");
        console.dump(this.testing(snapshot.getValue()));
        let result = {
          value : this.testing(snapshot.getValue()),
          type : "ValueChanged"
        };
        console.dump(result);
      },
      onCancelled: (databaseError) => {
        console.log(databaseError.getMessage());
        hideActivtiyIndicator();
      }
  });

It Returns the same dataset even if a new record is added that matched the query criteria.

Thank you

Yes, we experienced this behavior in our own apps. If you require up-to-date data with disk persistence enabled, you need to subscribe to all event value updates, not just call for a single value. It is particularly confusing because despite this behavior, Firebase will still call the server for a new value - it just won't return THAT one to you!

I filed a support request with Firebase about this and they said it was expected behavior. I also suggested they clarify the documentation and they said Thanks for this comprehensive feedback. We do value this kind of inputs from the developers. This will be included in our feature request list and will be discussed with our engineers. Unfortunately, I can't share any timeline or definite details as this will be monitored internally.

Hopefully that clarifies the situation. For what it's worth, we addressed this with a FIRDatabaseReference category (iOS, use appropriate metaphor for your platform) that adds an additional function. It calls SingleValueEvent and then calls it again 500ms later, returning the value both times to the caller. (The callback is taken with a weak reference in case the caller goes away in the meantime.) 500ms seems to be a good fit - the user is given an immediate value for display, and if they are offline or the network is slow, that's all they see. But if they're online and have decent network access, this gives them the latest data very shortly after.

  • 0
Reply Report