Summary on cell release and content disappearance of uitableview

The first problem is that a uitextfield is placed on a cell in tableview, and the content of textfield is removed after the screen is displayed. Later, we knew that the cell was replaced (not released), and then re-built a textfield, which is not the previous one, so it must be empty. However, it is interesting to see that if you are editing a textfield and you draw it out on the screen, the cell where the textfield is located will not be released, and the content is still there, however, this is not helpful for the whole. Uitableview will release the cell on the screen. There are several points to summarize: 1. This has nothing to do with reuse. I don't know whether it's from someone else's perspective or I thought wrong from the very beginning, the cell of uitableview is released only when the screen is drawn. My experiment is to add a _ weak modified uitableviewcell pointer member variable without reuse, and then let it point to a cell when tableviewcell is built, input the cell before building it.

<span style="font-size:18px;">@interface ViewController (){    __weak UITableViewCell* _testCell;    }</span>

<Span style = "font-size: 18px;">-(uitableviewcell *) tableview :( uitableview *) tableview cellforrowatindexpath :( nsindexpath *) indexpath {uitableviewcell * cell = nil; if (indexpath. row = 1) {nslog (@ "_ testcell >>>%@", _ testcell); If (_ testcell! = Nil) {return _ testcell; }}if (cell = nil) {Cell = [[uitableviewcell alloc] initwithstyle :( uitableviewcellstyledefault) reuseidentifier: @ "cell"]; uitextfield * textfield = [[uitextfield alloc] initwithframe: cgrectmake (10, 0,100, 44)]; textfield. tag= 1000; textfield. borderstyle = uitextborderstyleroundedrect; textfield. TEXT = @ "XXX"; [Cell addsubview: textfield];} If (indexpath. row = 1) {<span style = "white-space: pre"> </span> // reference 2nd cells, but the weak reference will not interfere with its original release _ testcell = cell;} return cell ;}</span>

If the input is not empty and the memory address is the same, it indicates that the referenced cell is not released. That is to say, the cell that draws the screen is not released, but why is the content in the cell changed? Because when the cell outside the screen enters the screen, tableview calls

<span style="font-size:18px;">-(UITableViewCell*)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath</span>

This delegate method, and then we will give it a new cell. That is, there is one tableview, and then you give it one, and the original one is squeezed out. So the key issue here becomes: In the above delegate method, whether to always return the difference between the newly built cell or the existing cell.

Why have you never paid attention to this problem before? In my own understanding, when I started to access tableview, I used it to carry the label. Because the label is not editable, the display content must have a fixed data source, such as an array filled with nsstring, and each time a cell is built, it will be displayed as a string, at this time, even if a new cell is used, there is no problem because the content will always be added again. While textfield is edited. Generally, the initial state does not assign text values to it. In this way, when a new cell is built, its content is blank, the edited content disappears. Therefore, the nature of label makes me not find these problems at the beginning.

How can I make textfield return content after the screen is drawn? Is to save the original content and call it again

<span style="font-size:18px;">-(UITableViewCell*)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath</span>

When the original items are lost. There are three layers: Save the cell, save the content bearer control (uitextfield, uibutton, etc.) on the cell, and save the content on the cell (such as the text in uitextfield ). The specific operation is:

(1) Save the cell: As mentioned above, the cell is not actually released, because we replaced the original cell with a new cell for tableview, resulting in the loss of the original content. Therefore, an array is required to store all cells, and then retrieve the cells from the array each time you need them. As mentioned above:

<Span style = "font-size: 18px;"> If (indexpath. row = 1) {nslog (@ "_ testcell >>>%@", _ testcell); If (_ testcell! = Nil) {<span style = "white-space: pre"> </span> // return the Cell Return _ testcell if it is not empty ;}} </span>

Of course, if an array is saved, you also need to add an identifier for each cell to filter out the correct ones from the array. According to this idea, the reuse mechanism of uitableview is directly changed. Isn't the cell reuseidentifier used for filtering? Although I don't know how to deal with the uitableview source code, I have read some source codes and have similar reuse mechanisms. They all put things into an array, then, if necessary, it will be retrieved and reused. So why should we build an array to save the cell instead of directly using the system for reuse? Because the reuse of the system is that the same reuseidentifier cell is universal, for example, if you have three cells in the same layout, assume they are a, B, c, then there is a uitextfield to fill in the content, so if they use the same reuseidentifier, then the system may give C to you when a is required, then it will be messy. If you build an array by yourself, filter and set your own identifiers, each cell will have its own unique identifier. This is the time for it, and it will never be heavy. Of course, in this way, all cells must be saved. Is there any risk in the content? In my understanding, generally, the tableview that needs to be input is not very long. It is impossible to have an interface. Do you need to manually enter 100 rows of information ?!

Another point is that cell = [tableview cellforrowatindexpath: indexpath] won't be able to retrieve the cell outside the screen. The document says and tries, even if the cell is not actually released.

(2) The control that saves the content to carry: This is too tired. Every time a cell is created, you must first determine whether the control exists and no build exists. Then add the control to the cell. If each cell looks different, then each cell must be determined separately.

(3) Save the content on the Cell: After the content is modified, save it, and enter the content back when the cell is built. This is actually quite tiring. The key is to save the content in real time. For example, textfield, you must set the delegate to store the content in time at the end of editing, otherwise, what will you give textfield next time? If there is a uitextview in this tableview, what about setting the uitextview delegate and the button? Suppose there are multiple of each of them? It must be distinguished, because there is only one delegate method.

Summary on cell release and content disappearance of uitableview