feat: FirebaseObservableMap

[jpventura]

I was not sure if I should PR this feature or discuss here first.

ObservableMap as a facade to event listeners

Basically I would like to know if we could provide a feature for hide read and write operations behind an ObservableMap. So all we would have to do to access data would be:

// Remote updates immediately send you your view
map.addOnMapChangedCallback(mUserChangedCallback);

// Non blocking operation to update database
Task<User> task = map.create(user);

// Local up-to-date cache
User user = map.get(primaryKey);

Relevant Code:

A detailed description is available at Stack Overflow and a working code at my repository fork.

[puf]

Where/how would you use such a ObservableMap?

[jpventura]

@puf It is more a readability improvement the functionality.

We are using Firebase in a project and I was trying to prevent the developers of writing too many nested listeners:

• Emulating Map interface, the read/write became more readable
• Sequence of tasks became simpler to write
• Rollback also became simpler, because oldValue is returned by the map and can restored

I was also trying to separate the model from the adapter, mainly due sorting. Instead of create a query reference and download the documents again, I was planning to also implement SortedMap interface.

[puf]

A map usually is a key-value collection with unspecified order semantics, where a Firebase DataSnapshot is an ordered key-value collection. So you're losing the ordering information.

Why don't you use the DataSnapshot instead? That also frees you from the adapter overhead, but then ensures you stick to the underlying system model.

I have no doubt you have good reasons for wanting this, but I don't see the advantages in usage. It may be easier to understand if you add some more code snippets on using the ObservableMap, comparing it to how you'd use a DataSnapshot or Firebase...Adapter in the same use-cases.

[samtstern]

@jpventura thanks for raising an issue to discuss this rather than going straight to a PR, that's always the right thing to do.

I agree with @puf, I am not familiar with this pattern and would like to see some more examples of how it's used and how that compares with normal Firebase usage patterns to understand the developer benefit.

[samtstern]

@jpventura it's been 3 weeks since the last update on this issue and I still am not totally clear on the use case. Hopefully what's being worked on in #544 will expand the extensibility of this library sufficiently to enable you and many other developers. If you think there's something else to be discussed, please comment on this issue and I'll re-open it.

[jpventura]

@samtstern, sorry for taking so long to answer, but it has being really hard save time for the open source projects. And yes, PR #544 provides all super powers I need to separate the model from view at the adapter :-)

But I must agree with @puf and I could not find a benefit of using ObservableMap besides code redability, which also can be achieved using Tasks API instead of nested listeners.

[samtstern]

@jpventura cool! Thanks for responding, I think we'll keep this closed and work on getting some form of #544 to happen so you and all the other devs out there can customize more.