1

Context:

  • Building an app that populates a table that takes in data from a asyc json dump.
  • The cells are of a custom class (I defined). The main label in the cell can be very long.
  • It is "placed" in storyboard within a prototype cell but customized via code (pretty standard stuff).
  • Labels are resized in cellForRowAtIndexPath and rows are resized via heightForRowAtIndexPath -- rows are resized by forcing a call to cellForRowAtIndex like Massimo's answer here

So per the question at hand - I've noticed some interesting (bad) things that happen.

First issue: When the table loads, the rows and labels are dynamically resized correctly! Great! However, when I scroll down and then scroll back up, the label heights will be incorrect -- (for example) the first row was correct at loading. Then when I scroll down and then scroll back up to see it again, it will be truncated. Specifically, the row size will be fine but the label height will change and become truncated to 2 lines only. Wondering if this is because I did both storyboard and coding to customize the cell. Anybody see this before?

Second issue: When I scroll down, while the rows are sized correctly (large), the labels are short (truncated.) Wondering if it's some reverse of the above "potential answer".

  • "potential answer" is that the rows are all calculated and stored "up front" so that scrolling down/then back up doesn't affect it. However, when cells go "out of view" and are dequeued then when they re-viewed (scroll down/then back up) it will rely on the storyboard.(inappropriately?)
Community
  • 1
  • 1
Andrew Chung
  • 417
  • 4
  • 15

2 Answers2

0

All three of your issues are symptomatic of returning the wrong height in heightForRowAtIndexPath. In my data model classes I have a calculateHeight method that I call in heightForRowAtIndexPath. The model also caches the answer so it doesn't have to recalculate it after the first call. The cell class uses the model's calculated height to layout its subviews.

jsd
  • 7,673
  • 5
  • 27
  • 47
  • thanks jsd - I'm going to do a little bit of digging but based on my initial view it really does look like it is spitting out good row heights and setting them AS IF the labels within the cells are set correctly. /n I have a feeling this is happening because I have three labels. Each one placed below the previous one and the top one being the "potentially" longest. Set up like this: cell.fDTitle.frame = CGRectMake(6, 0, 261, labelHeight); cell.fDSubtitle.frame = CGRectMake(6, labelHeight, 261, 21); cell.fDPoints.frame = CGRectMake(6, 23+labelHeight, 261, 21); – Andrew Chung Dec 04 '12 at 23:14
  • However, when I look at the simulation, queued cells seem to be following the format defined in the storyboard (in terms of cell height (but not row height) and in terms of the maximum length of the first label. (to clarify, you can clearly see that via code the placement of the labels are dictated by labelheight, however, it looks like in simulator the first label will be constrained the placement of the 2nd and 3rd label even though in storyboard I made the first label with a height almost as large as the iphone (just in case there was some forced limitation.) – Andrew Chung Dec 04 '12 at 23:23
  • One thing I find really helpful is to give the labels a solid color background so I can see where they are actually being drawn. How are you resizing the labels? I imagine they have to vary their heights in order to accomodate different amounts of text? You might also try not using labels at all and instead using NSString drawInRect... Then again labels are awfully convenient. Depends what you're doing really. – jsd Dec 05 '12 at 00:03
  • Yup :)I still have the storyboard but deleted the prototype cell-this seems to stop what i affectionately term, "the funky behavior". My hypothesis of why this is the case: the immediately displayed cells use the code however, once they get "put away" (queued) they rely somehow on the placement of the labels in the storyboard (as opposed to the labelHeight calculations. I think the greatest offender in this is the (upper left/top) of the placed UILabels in the storyboard; they seem to get respected and "override" the fact that the top (the long+ variable)label has space for more than 10 lines. – Andrew Chung Dec 05 '12 at 07:56
  • Thank you JSD - I appreciate your quick reply - very cool thank you! – Andrew Chung Dec 05 '12 at 07:57
0

"ANSWERED" by deleting the prototype cell from the storyboard and making them fully in code, the issue went away. The fundamental workings are still not understood (ie. the interactions between storyboard vs. code when cells are put queued and then viewed again)

Andrew Chung
  • 417
  • 4
  • 15