Sorting a filtered view

[Roni Brunn]

Hi Robbie,

Thanks again for your awesome answer to my last question. I'm well on my way with my project, and I'm really enjoying learning about YapDatabase - both the product and its documentation are just so great.

Two questions:

1. Can a filtered view have its own sorting, separate and different from the sorting of its parent view? If not, is there a recommended approach? My collection view will have an array of uuids in the desired order before it starts laying out its cells.
   
2. How do we know when the initial data download is done in a project like your Todo sample? I'd like to implement a progress spinner, and I'm figuring out when the view controller should disable it. The initial download of objects takes a relatively long time due to images.
   

Thanks you!

Roni

[Roni Brunn]

I figured out #2.

[Robbie Hanson]

> Can a filtered view have its own sorting, separate and different from the sorting of its parent view?

No, the filtered view is only capable of filtering. The idea is that it “inherits” the grouping & sorting logic of its parent. This is designed for “separation of concerns”. That is, you can modify the grouping/sorting logic of the parent, and the results automatically propagate to the child filtered view.

> If not, is there a recommended approach?

Generally, if a view needs it’s own custom sorting, the recommended approach is to make it a regular YapDatabaseView. Your view will simply use the same grouping block as another view.

In terms of CPU, you’re not really losing much here. While its true that you’re running the same grouping block twice, the overhead of a grouping block is nearly negligible in most cases.

And you’re not losing anything in terms of disk storage, as all views use the same storage mechanism. (They store their array(s) of rowids in their own dedicated table.)

That being said, this may change in the future...

When I first architected extensions on top of the core YapDatabase layer, I imagined eventually having a lot of extensions. Views, sets, secondary indexes... (and I haven’t even implemented Sets yet). And while I knew that Views were most likely going to be the most useful, I didn’t anticipate (at the time) all the different ways in which people wanted to use them.

I now regularly get feature requests like:

- I want to pipe the results from a secondary index into a View.

- I want to use a View, but I want to allow the user to manually sort it.

- I want a View to inherit the grouping from a parent view, but provide its own sorting.

- I want a View to support storing an object in multiple groups.

So this is both a good thing and a bad thing. It seems that people love using Views, and find them especially useful in powering tableViews & collectionViews. But obviously the current architecture of Views is too rigid. In order to start supporting all these other use cases, I’m going to have to make some big changes to the View code.

This is planned for a future release. Maybe 3.0.

-Robbie Hanson

--
You received this message because you are subscribed to the Google Groups "YapDatabase" group.
To unsubscribe from this group and stop receiving emails from it, send an email to yapdatabase...@googlegroups.com.
To post to this group, send email to yapda...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Roni Brunn]

Wow, that's awesome.  Thanks so much for your insights and for your thoughts about 3.0!