(grid) Resize triggers expensive reload


Suppose I have  a ShinobiDataGrid with a thousand rows.  It is in the detail pane of a splitview.  And it is scrolled down half way through the thousand rows.

And I have set the Autoresizing mask on the grid:

_grid.AutoresizingMask = UIViewAutoresizing.FlexibleWidth | UIViewAutoresizing.FlexibleHeight;

(I’m using C# here)

In this configuration, when I rotate the device, it triggers a reload of all the visible cells PLUS all the cells ABOVE the scroll position. It is calling PrepareCell... for roughly 500 rows of cells that it does not need.

I am wondering if this is a bug. It would seem to me that the grid should never reload the non-visible cells.

Without the AutoresizingMask line, it does not do this. But that leaves the grid in the wrong size for the new orientation of the splitview.

I do notice that none of the Xamarin samples set AutoresizingMask.


Further investigation shows this is worse than I thought.

ANY call to Reload() will cause PrepareCellForDisplay() to be called for every non-visible row above the scroll position (plus the visible rows, of course).

Resize is probably just one way to end up with a call to Reload().

I speculate that the grid needs to know the heights of all those non-visble rows so that it can determine which rows are visible.  However:

(1) Since I have not overridden HeightForRow in the Delegate, shouldn’t all rows be the same height, so the calculation can be just a simple multiply?

(2) Even if it needs to call the Delegate for all those non-visible rows, does it really need to call the DataSource too?


Hello Ericsink,

This is a known issue. The grid queries the heights of all the invisible rows just so we know their heights. As you say, we could just do a simple multiplication instead of this if the HeightForRow method hasn’t been implemented.

I have forwarded on the issue to our core development team and they will be looking to optimise this behaviour in a future release. However, it must be said that without a proper investigation into the optimisation, they couldn’t tell whether or not there could be other implementation details that could arise due to your suggested fix.

In the meantime, have you considered trying to put a guard in your PrepareCellForDisplay method, so that you don’t bother preparing a cell that isn’t going to be visible?

I hope the above has helped. We really appreciate any comments you have about the API or behaviour of our controls, so keep them coming! This type of thing helps us improve the quality of our controls, and that is exactly what we are always striving to do.