The multiplexing mechanism of cell in TableView

TableView reuse mechanism, in order to achieve display and data separation, IOS TableView implementation and not for each data item to create a TableCell. Instead of creating a screen to display the largest number of cell, and then reuse these cell, the cell to do a separate display configuration, to achieve neither the effect of the display, but also the purpose of saving the content. The following is a brief analysis of its implementation principle.

Reuse Implementation Analysis:

Looking at the UITableView header file, you will find nsmutablearray* visiablecells, and nsmutabledictnery* reusabletablecells two structures. Visiablecells saves the cells,reusabletablecells that are currently displayed to save reusable cells.

At the beginning of the TableView display, Reusabletablecells is empty, then TableView Dequeuereusablecellwithidentifier:cellidentifier returns nil. The starting cell is created by [[UITableViewCell alloc] Initwithstyle:uitableviewcellstyledefault Reuseidentifier:cellidentifier]. Also, the Cellforrowatindexpath only invokes the maximum number of cell displays.

For example: There are 100 data, the iphone screen displays up to 10 cell. The first thing the program shows TableView is:

1. Create 10 times cell with [[UITableViewCell alloc] Initwithstyle:uitableviewcellstyledefault Reuseidentifier:cellidentifier] The cell is also given the same reuse identity (and, of course, different identities can be specified for the cell with different display types). And all 10 of the cell are added to the Visiablecells array, and the Reusabletablecells is empty.

2. Drag down the TableView, when the cell1 is completely removed from the screen, and CELL11 (it is also alloc out, the reason above) is fully displayed. Cell11 added to the visiablecells,cell1 move out of Visiablecells,cell1 to join Reusabletablecells.

3. Then drag down the TableView, because there is already a value in the Reusabletablecells, so when the need to show the new Cell,cellforrowatindexpath is called again, TableView Dequeuereusablecellwithidentifier:cellidentifier, return to CELL1. Cell1 added to the visiablecells,cell1 move out of the reusabletablecells;cell2 move out of Visiablecells,cell2 to join the reusabletablecells. Then the cell that needs to be displayed can be reused properly.

So the whole process is not difficult to understand, but it is because of this reason: When configuring the cell must pay attention to the removed reuse of the cell do not leave the old data.

Some cases:

During use, I noticed that the Reusabletablecells table is not updated until the screen is dragged, as well as:

1. Reloaddata, this situation is more special. It is usually called when some of the data changes and needs to refresh the contents of the cell display. In the Cellforrowatindexpath call, all the cell is reused. I estimate that after the Reloaddata call, all the cell in the Visiablecells is moved into the reusabletablecells,visiablecells empty. After the Cellforrowatindexpath call, the reuse cell is removed from the reusabletablecells and put into the visiablecells.

2. Reloadrowsatindex, refresh the specified indexpath. If Reusabletablecells is empty at the time of the call, then after the Cellforrowatindexpath call, the new cell is created and the new cell is added to the visiablecells. The old cell moved out of Visiablecells and joined the Reusabletablecells. Then, after the refresh there is a cell to do reuse.

Attention:

1-the removed cell is likely to have been bundled with data or added to the child view, so if necessary, clear the data (such as Textlabel text) and remove the add from the child view (using tag).
2-The purpose of this design is to avoid frequent alloc and Delloc cell objects, not much more complicated.
3-The key to design is to achieve complete separation of cell and data

Focus: Avoid reuse mechanism errors

1. The reuse mechanism calls the Dequeuereusablecellwithidentifier method, which means "column reusable cell", So as long as it's replaced by Cellforrowatindexpath (the cell from the same line as the cell to be updated), you can use no reuse mechanism, so the problem can be solved, but it will waste some space

2. Specify a different reuse identifier (reuseidentifier) for each cell to resolve. The reuse mechanism is to reuse the cell based on the same identifier, and the cell with different identifiers cannot be reused.

[CPP] view plain copy print? NSString *identifier = [NSString stringwithformat:@ "timelinecell%d%d", Indexpath.section,indexpath.row];
3. Delete all the child views of the reused cell so that a cell without a special format can be reused by other cell.

[CPP]  View plain copy print? if  (cell == nil)  {            cell  = [[uitableviewcell alloc] initwithstyle:uitableviewcellstyledefault reuseidentifier :identifier];        }        else         {            // Deletes all child views of the cell             while  ([ Cell.contentview.subviews lastobject] != nil)              {                [ (uiview*) [cell.contentview.subviews lastobject] removefromsuperview];             }        }