Two columns with staggered cells

[anomalousunderdog]

I'm going to try making a setup like this:

The ones labeled "Holy High Five" are the cell views in this example.



I'll highlight the shapes of the cell views to illustrate better:



As you can see, I want each cell view with their own height, and I also want it for 2 columns.

So far this is only a mockup inside Unity, two gameobjects acting as the columns, each with its own Vertical Layout Group. The ones I colored green is the 1st Vertical Layout Group, and the ones colored yellow is the 2nd.

The divider that says "Tier II (10)" is actually two cell views that are made to line up, as shown in the 2nd screenshot, so they need to somehow communicate with each other (and get the sizes on the cells above them) to determine what their height will be.

I've read a bit on the source code for EnhancedScroller.cs, I also looked at the demo scenes "08 View Driven Cell Sizes" and "02 Multiple Cell Types", and I think I got the gist of it, so I'll give it a shot and edit it to make this work.

Just want to know if any of you have done anything similar and point me in the right direction how to do this, thanks!

[echo17]

Hmm, that is fairly complex. Thanks for the screenshot, that helps explain a lot!

I would recommend some combination of nested scrollers. It looks like each "tier" in your screenshot could be a cell for an overall scroller. Inside those tier cells, you could have two other scrollers, each with their own set up vertical scrollers.

For example:

Purple: overall scroller
Blue: vertical cells in the purple scroller, one for each tier. Each of these cells contain two vertical scrollers (orange). You could actually make this dynamic and have a single horizontal scroller in the blue cell that contains cells, each with their own orange vertical scroller. If you just need the two columns, I would stick with a static two scrollers in the single blue cell, though, to keep it simple.
Orange: vertical scrollers in the blue cells
Green: cells containing the actual data to display.

There are probably numerous ways to do this, but that seems the easiest. Check out Demo #12 for an example of nested scrollers.

[anomalousunderdog]

Hi, thanks for the reply!

I couldn't wrap my head around how to use nested EnhancedScrollers, because I need all of it to be controlled via one scrollbar, and I wasn't sure how to do that.

I just ended up continuing with editing EnhancedScroller.cs and came up with this so far:



It works ok but I really made a mess with my edits, I may clean it up later on. CellViews go in either of the two Columns as seen in the Hierarchy Panel there. Both columns are managed by the EnhancedScroller.

I haven't made looping and snapping work with this, simply because I don't need those features.

[echo17]

Very nice, thanks for sharing!

[anomalousunderdog]

Hello again, just want to give a quick update that I also managed to get those dividers working too:



As shown there, the divider is actually a pair of cell views, one for the left column (where the text is shown) and another for the right column. They're always made to line up with each other. That's done by having their height be calculated using the cellviews above them.

I do get some noticeable lag when I add new rows during runtime, as I based this on the "View Driven Cell Sizes" demo, which recalculates all cell view sizes whenever I add a new row.

Since it's just adding data at the very bottom, I do wonder if that's really necessary. Even if I were to add data in the middle of the list, cell view sizes of the existing cells shouldn't need recalculating, it's only the cell view offsets that really need to be updated, and I do think it should only need to recalculate offsets starting from the newly added cell up to the ones below it (shouldn't need to modify the offsets above it). It kinda breaks when I try that, so I'll leave that for another time.

[echo17]

That is very, very cool.

Feb 27, 2019 15:34:47 GMT anomalousunderdog said:

It kinda breaks when I try that, so I'll leave that for another time.

I think I had a similar thought process and tried to do the same thing you are and was not succeeding. I believe it has something to do with the order of operations in Unity's UI layout calculations. I believe it calculates the necessary space for elements as the very last step of the frame, so that is why I have to defer the cell height adjustments until the second pass through after those layout elements are set. Might be a related issue to why the whole set of offsets has to be calculated, but I can't remember for sure.