Reputation: 6358
In my app I have set observers for childAdded
, childDeleted
and childModified
on the Firebase database nodes of interest to keep track of them and modify my CoreData
device database accordingly. I just realised that if a childDeleted
or childModified
happens when a device is not online, it won't get notified of those events when it goes online again. As it is the normal expected behaviour as understood, I thought of a workaround as so: when I trigger deletion an entry on Firebase node, I will create an entry of the respective "deleted" node. So a childAdded
event will be triggered when device gets back online and perform the logic that is now performed by the childDeleted
observer. This way I won't observe any childDeleted
events.
So my question is: am I misusing Firebase observers ,and childDeleted
should be communicated anyway when the device gets back online, or this kind of situation is actually the way it is supposed to work? What kind of solutions did you implement in this situation?
Upvotes: 2
Views: 66
Reputation: 598847
The Firebase Realtime Database synchronizes the state of the data on the server with any connected clients. Whenever a client (re)connects, Firebase makes sure that client has the current state of the data. As you've discovered Firebase explicitly does not synchronize state changes.
If you want to synchronize state changes, you should store precisely those state changes in the database. Because then those changes becomes the data that Firebase synchronizes.
So your solution is fine, and is in fact the idiomatic way to handle this requirement.
Upvotes: 1