Is this an UITableView -beginUpdates documentation error?

I can't wrap my head around what they tried to say here in the docs for -beginUpdate:

Call this method if you want subsequent insertions, deletion, and selection operations (for example, cellForRowAtIndexPath: and indexPathsForVisibleRows) to be animated simultaneously.

Let's see... cellForRowAtIndexPath: and indexPathsForVisibleRows are both GETTER methods. They do not update anyt开发者_运维百科hing and do not change anything. So why should I call -beginUpdates before calling these? And what's animated regarding these? Well, nothing, huh? Just want to make sure this is really an error in the docs and I didn't miss something.

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.

It's probably not an error. It lets you perform a set of operations (that include but are not limited to cellForRowAtIndexPath: and indexPathsForVisibleRows) that likely include adding, removing, and reordering rows. Putting a set of these operations in a beginUpdate/endUpdate block will cause them to animate simultaneously.