Reload cell item with a new size about gmgridview

[steipete]

I'm not sure if it's possible to have different cell sizes - i hardly think so (but I'm not the author).
If you need to change the size, reloadData is probably the way to go.

[malcommac]

Yeah you're right, that's a mistake of mine :)
Okay it could be a to-do feature :P

[steipete]

I believe the goals of this grid project are different - allowing custom-sized cells is a whole different bag of pain.
You can use same-sized cells and use different size within - so that the absolute border to the next cell is the same.

[gmoledina]

Yes the grid does not support different sizes per cell; it's just a grid.

Support for different sizes per orientation will be added soon though.

[dxclancy]

There are actually 2 ways to approach this. Assume ,for instance, that you want variable heights:

1. A GMGridViewLayoutVerticalVariableHeightStrategy that has no access to the datasource.

• it merely caches cell sizes as it produces them, based on previously seen sizes.
• this is much more difficult, and requires more modification in the core code.
• A theme of the changes in core revolve around being able to handle unbounded ranges or sizes, and then checking continuously as new origins are asked for to notice when the range or contentSize is now determined.
• I have hacked together some stuff to do this, but it still suffers from content scrolls that are fast enough to not have asked for all previous cells when asking for a position origin. (since it will not have cached those position frames)
• A VariableHeightLayoutStrategy that is constructed with access to the datasource. It can then maintain its own cache of cell sizes by asking the datasource directly. Less change is needed to the core code for this approach.
• the major theme here, which is also needed in approach 1, is to have the core code act on and pass along the actual cell sizes, instead of the dataSource "size" which in this case is more of a maxSize.

Also, for this type of strategy, it is probably best to convert layout strategies to return NSIndexedSet instead of NSRange, as you may have to say that 0 - 45 is in bounds, but yet only half of those cells may be in bounds depending on how the heights stack up. Without this, your views and cache are bigger than they may need to be, which maybe isn't a big deal.

Note that i've only experimented with getting a layout and scrolling, not with any of the movement/editing/dragging/zooming etc...

[dxclancy]

http://i.imgur.com/l7rFv.jpg

[gmoledina]

Nice! One other way would be to have blocks in the layoutStrategy classes to compute the cellSizes. So the grid would set the block of the layout strategy and in it's implementation, call the datasource. The layout would just run the block to get the cellSize for each cell whenever needed; this way, the layout strategy doesn't know anything about the data source.

How are the cells aligned at the end of the scroll ?

[dxclancy]

I wasn't sure if you wanted the grid involved, so for now i just construct the strategy with a protocol that produces the sizes.

by aligned, do you mean visually at the bottom of the scroll? however they stack up. You can end up with a bunch of "jagged" white space. although i have an idea for how to make it look better.