xmartlabs/XLForm

Another case of rows disappearing after scroll

Open

#725 opened on Feb 9, 2016

View on GitHub
 (1 comment) (0 reactions) (0 assignees)Objective-C (5,786 stars) (969 forks)batch import
help wantedquestion

Description

There was another closed issue "Rows disappear after scroll", but it looks like this is different.

I'm working with a modification of the example app with my section added before "Real examples", in it is my own cell and then a XLFormRowDescriptorTypeDateInline. My row's cell is similar to XLFormDateCell but overrides textLabel and makes it span 2 lines when the title is a long string. This seems to be relevant somehow since when I only have my cells that have short titles and use the table's normal cell height, my problem doesn't happen. Looking at what is specifically happening, though, I can't see the connection, but maybe its something someone else has seen. Essentially, it looks like the tableview is trying to remove cells as they scroll out of view, but its removing the wrong cells.

I'm using a minor modification to XLFormViewController which has some experiments I'm doing to tableView:heightForRowAtIndexPath: and tableView:estimatedHeightForRowAtIndexPath: but they're essentially the same, and also implements tableView:didEndDisplayingCell:forRowAtIndexPath: so I can log when that's called.

Ok, what I'm doing and what's occurring:

  • all look good when displayed initially, tableView:heightForRowAtIndexPath: and tableView:estimatedHeightForRowAtIndexPath: are both returning 64 for my cell, 44 for all other cells
  • visible index paths (section/row) are: 0/0-1 (my section with my custom cell & a standard date cell), 1/0 ("iOS Calendar Event Form"), 2/0-3 ("Text Fields", "Selectors", ...), 3/0 ("Multivalued Sections")
  • I scroll down until my cell is removed, in the process cells are added at index paths 3/1 & 3/2
  • I scroll back up to the top, the tableview tries to remove 3/2, add 0/0, and finally remove 3/1, and 3/0...
  • tableView:didEndDisplayingCell:forRowAtIndexPath: is first called with index path 3/2, but with the cell for index path 1/0 ("iOS Calendar Event Form")
  • tableView:didEndDisplayingCell:forRowAtIndexPath: is next called with index path 3/1, but with the cell for index path 0/1 (the standard date cell in my section)
  • tableView:didEndDisplayingCell:forRowAtIndexPath: is lastly called with index path 3/0, but with the cell for index path 0/0 (my custom cell in my section)

The wrong cells passed to tableView:didEndDisplayingCell:forRowAtIndexPath: are indeed the same instances that were initially created and passed to tableView:willDisplayCell:forRowAtIndexPath:.

I'm running this in the simulator, iPhone 5s / iOS 8.4 and iOS 9.2. I'll be able to try on a real device this evening.

Does anyone know what could be happening?

Contributor guide

Tech stack
objective c
Domain
mobile
Issue type
bug
DifficultyEstimated implementation difficulty for a new contributor, from 1 for very small changes to 5 for expert-level work.
3
Estimated timeA rough time range for an experienced contributor to investigate, implement, test, and prepare a pull request.
1-3 hours
Activity statusHow available the issue appears right now: fresh, active, stale, blocked, or waiting on maintainer input.
stale
ClarityHow clearly the issue explains the expected change, acceptance criteria, and next step.
mostly clear
Prerequisites
iOS developmentUITableView cell reuse
Newbie friendlinessA 1-100 score estimating how approachable this issue is for first-time contributors.
20
Research direction
Investigate the modifications to tableView:heightForRowAtIndexPath: and tableView:estimatedHeightForRowAtIndexPath: in the user's custom XLFormViewController. Check how XLForm manages cell reuse and whether the estimated row heights are consistent. Consider if the issue is related to the two line text label causing incorrect height calculations. Look at the XLForm source code for cell registration and dequeuing logic.