Ability to have sections in FirebaseTableViewDataSource

[kermankohli]

It'd be really helpful if FirebaseTableViewDataSource.m allowed for UITableViewSections based on a specific variable. Basically something similar to NSFetchedResultsController used for Core Data 👍

[asciimike]

@kermankohli Yep, this would definitely be useful. I put some thought into this earlier, and my original thought was to use separate refs, so you would create a FirebaseTableViewDataSource and then add a section to it, and a section would contain a ref (or more likely a query). The approach mentioned above could allow for just a single ref, assuming you wanted to filter the data into sections based on the content of a single field.

This might fit in well for our eventual support for better client side filtering, so definitely on the roadmap after auth. It requires an array of arrays to support sections, adding inSection:indexPath.section adding numberOfSections... as [metaArray count] and then updating the correct array every time an event is raised. PR's welcome if you wanted to try before we got to it :)

[kermankohli]

@mcdonamp Alright, thanks for that! I'm not implementing Firebase right now but will be looking to move in about a month - do you reckon it'd be implemented by then?

[asciimike]

Thanks to @pmodernme, it might be earlier: #13

[kermankohli]

@mcdonamp looks pretty good, thanks @pmodernme! 👍

[pmodernme]

Happy to be of use!

[kermankohli]

Hey guys just had a question,

If the refQuery was users/john/tasks (which contains the IDs of all the users), how would filtering/sorting work in that case?

[pmodernme]

@kermankohli
As my sectioning fork is currently...

If you don't set the predicate, or the sort descriptors (set them to nil), it will sort the snapshots alphabetically by key.

If you set the sortDescriptors (this is an array of NSSortDescriptors), it will sort first by the zeroth sort descriptor, then the first, and so on. The sort descriptor queries the snapshot. So you could do:

@[[[NSSortDescriptor alloc] initWithKey:@"value.origin_date" ascending:NO]];
This will order by the origin_date child of the snapshot, with the largest value at the top.

or

@[[[NSSortDescriptor alloc] initWithKey:@"key" ascending:YES]];
This will order by the key of the snapshot (the last key path of the ref).

You have to use a key path like value.name to query the value.

Predicates work much in the same way. You set the predicate to an NSPredicate.

[NSPredicate predicateWithFormat:@"%K == %@", @"value.hidden", @NO];

Only snapshots with the child hidden with a value of FALSE will be shown.

I hope that helps!

[kermankohli]

@pmodernme

Thanks for such a detailed write up! Just read back on what I wrote and I ended up confusing my self 👎

What I meant to say was if the refQuery was /users/john/tasks/ (which contains an array of tasks who's ids correspond to the task class) then how would sorting work, because the values themselves haven't been fetched.

Sorry for the confusion before!

[asciimike]

What you're asking about is join functionality on top of the filtering, which we don't currently support. We're investigating something similar to what Firebase-Util offers in that respect, but, to be honest, doing all of that client side is really not something that we're interested in doing from a performance standpoint.

[kermankohli]

Yeah it's kinda an edge case which might not be worth developing for. Would it be fine if I structured my data to look like /tasks/john/taskX rather /tasks/(tasks from /users/john/tasks/)?

[asciimike]

It's a totally valid use case, it's just not something we support out of the box on the backend (being the type of NoSQL database we are). It's fine if you structure it that way, the issue is just that potentially pulling down all that task data and sorting it client side could be a pretty expensive operation.

Typically I recommend only pulling down the minimum amount of data required to sort/filter client side and then attach listeners on the relevant tasks/objects and grab those more full changes. Typically, for instance, you aren't filtering off the title or the description of the task (and those are relatively big), but you might be filtering off timestamps/tags, so keep the title/description in tasks/$taskID while putting other info in users/john/tasks/$taskID or similar.

[kermankohli]

Right gotchya. In my case I need to sort/filter by 5 keys, so in that case I'll need to store all that information in users/john/tasks/$taskID?

[pmodernme]

Ah! I have something similar in my own app. You have to sort or fetch by
something in the snapshot.
In mine, I have a list of subscriptions with basically just a timestamp,
Boolean, and an id for the data it relates too. The predicate is based on
the Boolean, and the sort is based on the timestamp. Then I use another ref
to populate the cell.

[kermankohli]

That makes sense! Doesn't it lead to duplication of data though? Or is this normal when you denormalize data (I'm new to this haha)?

[asciimike]

Yes, it can, though this is more normal in a NoSQL database--disk space is cheap, your time is not. It's effectively creating indices rather than relying on the DB to do so. Plus, with multi-writes in Firebase, it's easy to keep these values in sync.

[asciimike]

Closing because pull #13 deals with this

[cgossain]

I've built an NSFetchedResultsController type solution for the Firebase Realtime Database, and I've just open sourced it. I've been using this in a few of my production apps for some time now.

https://github.com/cgossain/FirebaseResultsController

I'd love to hear your thoughts.