CODEWITHSUNDEEP
iosuitableview
shoe
shoe

Reputation: 1070

Tableview cell not being recycled when it contains the first responder

I have a UITableView with about 30 items in it. The row height is static, and based on the size of the tableview, approximately 8 cells exist at any given time. Each cell has a single UITextField and that is it. The confusing part is when I begin to edit let's say the textfield in the cell at row 0. What happens is everything works as I would expect, until the row is scrolled out of visibility (whilst its text field is still the first responder). I would expect a cell down the line to also have a text field with the first responder status, as it is the cell that was just being edited, but recycled for another row — that never happens.

The cell at row 0 continues to hold the first responder status. I know this because I continue typing while scrolled all the way to the bottom (cell from first row would have normally been recycled by then), and what I typed is evident in the cell at row 0 once scrolled back to the top.

To be clear this is the behavior I want, but I haven't found it documented anywhere so it makes me weary of depending on it. The text entered into the cell's text field is stored as the name property of a model, and weird behavior would arise if a user thought they were editing the name of the model at row 0, but because of a future change to the iOS SDK, they end up actually editing the name of the model at whatever row the cell happens to be at when they're typing.

Upvotes: 2

Views: 72

Answers (1)

DonMag
DonMag

Reputation: 77462

I assume Apple added the .keyboardDismissMode to make text field resigning easier (automatic).

From Apple's Docs dequeueReusableCell(withIdentifier:) :

A table view maintains a queue or list of UITableViewCell objects that the data source has marked for reuse.

Which seems to indicate that, in some cases (such as this one), UITableViewCell objects will not be available for reuse.

We can at least confirm this, by inspecting the queue along with the visible cells:

print(tableView.value(forKey: "_reusableTableCells"))
tableView.visibleCells.forEach {
    print($0)
}

If we view this while scrolling up and down, we can see cells being used and being put into the queue.

But, if start editing a field in a cell, then scroll around without resigning it, we'll see that specific cell does not get put into the reuse queue.

Does that mean this behavior will never change? I couldn't tell you.

But, combining that information along with the fact that a UITextField does not resignFirstResponder simply by positioning it outside the frame / bounds of its superview, leads me to believe the behavior is by design.

Upvotes: 1

Related Questions