Add support for FUIArray and data source transformations

[morganchen12]

This is something that's been requested frequently (#93, #169). Two things I definitely want to add are map and sort. Not sure if we should add filter, since it may encourage people to download much more data than their app ever intends on displaying.

This most likely won't make it into the FirebaseUI 1.0.0 release.

[morganchen12]

Preliminary work on this can be found here.

Goals:

• FirebaseArray and friends abstracted behind FIRCollection protocol, so consumers don't have to care about the details of their collections if they don't want to. Users will also be able to define their own FIRCollections.
• Remove query observation from initialization of FIRCollections. This way initializers don't have side effects.
• Change data sources' designated initializers to take FIRCollections. This way a data source can be initialized with a normal, sorted, or mapped array without concern over the details of the array. Decouples data sources from their storage dependencies. The current initializers can be kept around, but this is still a breaking change since people who subclass the data sources will have to override a different initializer. Data sources are now responsible for telling their collections to observe their respective queries.

@mcdonamp lemme know if you have feedback

[asciimike]

Let's make sure we have a corresponding bug filed for Android as well.

[muirandy]

+1
This sounds exactly what I'm looking for.

I'm wanting to display a tableView, however I'm unable to get exactly what I need form the firebase query, as its either not sorted or not filtered - I can't have them both on the query itself (a well known issue/feature of Firebase!).

I want to be able to create my own implementation of FUIArray, which I can sort and filter as needed. At the moment, I can't do this without also writing my own DataSource.

> "Two things I definitely want to add are map and sort. Not sure if we should add filter, since it may encourage people to download much more data than their app ever intends on displaying."

Please do implement filter as well as sort! I understand the concern regarding performance and the download size, however, at least in my case this isn't going to be an issue - I'm dealing with relatively small amounts of data.

[muirandy]

I'd love to be able to move forward. Would it be possible to meet half way? For instance, refactoring to use a FIRCollection protocol (and it looks like this is already progressing - although I'm not sure how far its got) would probably allow me to create my own implementation - allowing me to sort and/or filter to my needs.

[morganchen12]

@muirandy The PR is basically ready to be merged, we're just waiting on Android since we want to maintain feature parity between the two codebases. Even though filter is left unimplemented, FIRCollection is publicly available and you can conform your own filtered collection to it.

[morganchen12]

#186 has been merged. Release coming soon.

[morganchen12]

v2.0.0 has been released.

[cgossain]

Just in case people need an NSFetchedResultsController type solution for the Firebase Realtime Database, I've just open sourced a library I've been working on for some time. I've been using this in a few of my production apps for some time now. And it includes support for diffing.

https://github.com/cgossain/FirebaseResultsController

I'd love to hear your thoughts.