1

I am wondering what exactly happens, when you dont use dequeueReusableCellWithIdentifier in the cellForRowAtIndexPath-method. In one Project I am collaborating we have different types of custom UITableViewCells which all appear in one single tableview. So here we fill arrays with all TableCells that should be displayed. These arrays are not very big (10-15 Cells) so for us that way works even not using any identifiers for dequeueReusableCellWithIdentifier. The next question is how at all you could use identifiers resp. dequeueReusableCellWithIdentifier when using different Cells in one single section of an UITableView. Is someone here hwo can explain, what exactly happens in background? Regards Nils

Wain
  • 118,658
  • 15
  • 128
  • 151
Nils Holland-Cunz
  • 13
  • 4
  • does it matter what happens in the background to you? i mean it does, because you can break the table view cell cache pretty easily, but your question seems unrelated to how the dequeue works and more about how you might use identifiers ? – Wain Apr 28 '16 at 12:34
  • 1
    It's all about "reuse". That's the import part in that method name. It allows to reuse cells that have been out of screen instead of reallocating a new one each time. In other word: Saving CPU, Memory (cache system), etc. – Larme Apr 28 '16 at 12:35
  • That is right Wain. We dont use identifiers in the mentioned case, because we simply dont know how when we have different custom cells in one section. Do you have any suggestions? – Nils Holland-Cunz Apr 28 '16 at 13:15
  • You can use something like that: http://stackoverflow.com/questions/1405688/2-different-types-of-custom-uitableviewcells-in-uitableview – Larme Apr 28 '16 at 13:32
  • Looks good! thank you! – Nils Holland-Cunz Apr 28 '16 at 13:50

1 Answers1

4

The dequeueReusableCellWithIdentifier is something that reminds me of Flyweight pattern.
Since allocation and instantiation of a cell can be an expensive task, using this mechanism you have the opportunity to create only the first visible cells and later reuse them just changing their contents. Scrolling animation must be as fast as possible to give a good experience to the user.
Is it worth it? Yes and it basically comes for free, we just need to pay attention that some old data can be still present in a new visualization, the trick is to always implement the method -prepareForReuse() correctly, here, you can eventually wipe all displayed data before setting the new one.

If you want to use different cells in the same section is absolutely possible, also if they have different height. You just need to crate different cell identifiers, one for each cells and tie them somehow along with your data.
I usually map data to be displayed in struct (swift) or dictionaries along with a key for the cell identifier to be used.
If your type of cells are representing themselves while scrolling you should dequeue them.

Andrea
  • 26,120
  • 10
  • 85
  • 131