Let's see... cellForRowAtIndexPath:
and indexPathsForVisibleRows are both
GETTER methods
They are only getter methods from the perspective of one of the objects in the message exchange. For the other, they are involved in setting a value.
cellForRowAtIndexPath:
is a getter in the tableview datasource object but the tableview uses it to set the value of a cell for a particular row. Likewise, indexPathsForVisibleRows
is a getter in the tableview object but another object will use it to set the value of the rows it will access.
In the case of the beginUpdate
block, both these messages pass information that might be in flux because the user is directly altering the table's displayed rows using the UI.
So why should I call -beginUpdates
before calling these?
You don't unless the user is directly manipulating the row order of the table with the UI. Otherwise, you don't use the beginUpdates
block at all. I only use it for about 1 in 5 of my tables.
And what's animated regarding these?
The UI is showing the user an animation of rows being moved, inserted or deleted.
From your previous five questions I believe you are under the impression that the beginUpdates
block is a central critical feature of tables and that you can't use tables without implementing the block.
This is not the case. You only need to use it when you allow the user to directly edit the rows (not cell contents but the position of the entire cell in the table itself.)
The block just temporarily freezes the behind the scenes logic of the table so that the changes made by the user can be synced with the existing data. Without the block, the table will try to redraw itself using the data that was in place before the edit began.