IOS uitableviewcell Reuse

When cell is used in the process of writing the Sina Weibo interface, some controls are added to the cell. However, because the content of each microblog is different, during the display process, there is a problem of overlapping content, which is actually a problem of the uitableviewcell reuse mechanism.

- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath{    static NSString *CellIdentifier = @"Cell";        UITableViewCell *cell = [tableView dequeueReusableCellWithIdentifier:CellIdentifier];    if (cell == nil) {        cell = [[UITableViewCell alloc] initWithStyle:UITableViewCellStyleDefault reuseIdentifier:CellIdentifier];    }        return cell;}

Tableview reuse mechanism. To achieve display and data separation, IOS tableview does not create a tablecell for each data item. Instead, create the largest number of cells that can be displayed on the screen, and then reuse these cells to separately display the cells, so that the display effect is not affected, in addition, it can fully save content.

Solution 1:How to Set tags for controls added in Cell

For example, if you need to add a label to the Weibo content, you can set a tag for the added label. When creating a cell, remove the label with the same tag as the previous cell, and then add a new label, in this way, there will be no overlap of cell content.

[[Cell viewwithtag: 100] removefromsuperview];

[[Cell contentview] addsubview: contentlabel];

Solution 2:Delete all child views in a cell

In the microblogs interface, a cell has multiple controls (Label, imageview ...), it is reasonable to set a tag for each control. The first solution should be feasible. However, the problem of overlapping content still occurs when the system is not running. Therefore, the second solution is to delete all the child views when creating a cell.

If (cell! = Nil) {[Cell removefromsuperview]; // process reuse}

Solution 3:You can solve this problem by specifying different reuseidentifier for each cell.

The reuse mechanism is to reuse cells based on the same identifiers. Cells with different identifiers cannot reuse each other. Therefore, we can avoid cell reuse by setting the identifiers of each cell to different ones.

-(Uitableviewcell *) tableview :( uitableview *) tableview cellforrowatindexpath :( nsindexpath *) indexpath {nsstring * cellidentifier = [nsstring stringwithformat: @ "cell % d", [indexpath section], [indexpath row]; // use indexpath to uniquely determine the cell uitableviewcell * cell = [tableview dequeuereusablecellwithidentifier: cellidentifier]; // output reusable cell if (cell = nil) {Cell = [[uitableviewcell alloc] initwithstyle: uitableviewcellstyledefault reuseidentifier: cellidentifier];} //... other code}

This method has not been used. Record it first.

The following content comes from blog http://blog.csdn.net/omegayy/article/details/7356823

Reuse Implementation Analysis

View the uitableview header file and find the nsmutablearray * visiablecells and nsmutabledictnery * reusabletablecells structures. In visiablecells, save the currently displayed cells, and reusabletablecells save reusable cells.

When tableview is displayed, reusabletablecells is empty, tableview dequeuereusablecellwithidentifier: cellidentifier returns nil. The initial cell is created through [[uitableviewcell alloc] initwithstyle: uitableviewcellstyledefault reuseidentifier: cellidentifier], and cellforrowatindexpath is only the number of times that the maximum number of cells is displayed.

For example, if there are 100 data records, the iPhone can display up to 10 cells on a single screen. When the program first displays tableview:

1. use [[uitableviewcell alloc] initwithstyle: uitableviewcellstyledefault reuseidentifier: cellidentifier] to create a cell 10 times and specify the same reuse ID for the Cell (of course, you can specify different identifiers for cells of different display types ). All 10 cells are added to the visiablecells array, and reusabletablecells is empty.

2. Drag tableview down. When cell1 is completely removed from the screen and cell11 (it is also alloc, the same as above) is completely displayed. Cell11 is added to visiablecells, cell1 is removed from visiablecells, and cell1 is added to reusabletablecells.

3. Drag tableview down. Because there is already a value in reusabletablecells, tableview dequeuereusablecellwithidentifier: cellidentifier and cell1 is returned when you need to display a new cell and cellforrowatindexpath. Cell1 is added to visiablecells, cell1 is removed from reusabletablecells, cell2 is removed from visiablecells, and cell2 is added to reusabletablecells. Then the cell to be displayed can be reused normally.

Therefore, the entire process is not difficult to understand, but it is precisely for this reason: When configuring the cell, you must pay attention to re-assigning values to the reused cell to avoid legacy data.

Some situations

During usage, I noticed that the reusabletablecells table is not updated only when the screen is dragged:

1. reloaddata, which is special. This is generally called when some data changes and the content displayed by the cell needs to be refreshed again. In the cellforrowatindexpath call, all cells are reused. I estimate that after reloaddata is called, all cells in visiablecells will be moved into reusabletablecells and visiablecells will be cleared. After cellforrowatindexpath is called, obtain the reuse cell from reusabletablecells and put it into visiablecells.

2. reloadrowsatindex: refresh the specified indexpath. If reusabletablecells is empty during the call, after cellforrowatindexpath is called, a new cell is created and the new cell is added to visiablecells. Remove the old cell from visiablecells and add it to reusabletablecells. As a result, the cell is reuse after the refresh.