Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>That is not gong to work. Aparently you did not yet fully understand how the re-use mechanism works. </p> <p>What do you do? First you fetch a cell to be re-used. If you get one -fine so far but the problem comes later. If you don't get one then you create a new one. </p> <p>When you have created a new one, which is the case at start before the user begins scrolling, then you add some UIItems depending on section and row. I will explain why this is not actually a smart thing to do. </p> <p>Then the user scrolls. Cells will dissappear from screen and then made available for re-use. Then you will fetch the cells for re-use. But it may well happen that those cells already have additional UI-Items on them because you have used them before in that way. In the following process you will add new UI Items regardless whether there are already additional UI-Items on that very cell. </p> <p>What can you do: </p> <ol> <li><p>Create your own custom table cell subclasses. One subclass for each set of additional ui items that you may need. That is probably the neatest way of doing it. For each subclass use a different re-use identifier (!!!) This is what I would recommend! However, there are alternatives:</p></li> <li><p>You could still live with your concept but invent an individual type of re-use identfier for each type of cell that has some type of additional ui item on it. If so, then make sure that these UI items are only created and added as sub-views in the <code>if (cell == nil)</code> branch of your code. Only create them once and then re-use them. Cell reuse-IDs could be "email-display", "email-input" , "password-display", "password-input", "switch", ... </p></li> <li><p>A variance of the solution above would be, to calculate row and section into the reuse-identifier. Such as "cell-id-0.2" for section 0 and row 2 - or so. But still you will have to make sure that you really re-use the additional UI views and do not re-create them every time when the cell is filled with data. Plus, the layout in your first section varies depending on whether you want to input password and e-mail or just display them. You will still have to deal with those variations. </p></li> <li><p>If cell == nil - meaning if a cell is re-used - then first clean it from every UI item that you may have added before. You can do that by tagging your UIViews with - let's say 99 - (anything different from 0 should do) upon creation and when reusing enumerate over all subviews and remove those, which have the tag 99. Despite that you can stick with the code that you have already made. </p></li> </ol>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload