I got a problem with the Tableview-Cells in iOS.
I got a tableview with custon cells in it. I wanted to lower the height of the cells.
The row height in the tableview was set to 105, I changed it to 55 (the actual height of the custom cells wich are provided as xib-files).
So far, so easy, but now to my problem:
After the tableview loaded, it showed only one entry, but all the other entries aren't shown. If I scroll down and up again on the other hand, the previously hidden entries are shown.
I tried to work a little with the heigh-values in the tableview-options, and as I increase the heigh the more of a cell is shown on the first loading, but its never a complete cell until I set it to 105 again. Scrolling fixes the broken entries.
There is by far enough size on the screen and the cells height is exactly 55.
Has anyone here has an idea what could cause that problem?
As allways, thanks for any help.
Related
I'm seeing another case of UITableView cells disappearing unexpectedly when scrolling, but none of the similar questions & answers here I've seen really fit what I'm seeing:
I scroll down until my top cell is removed and tableView:didEndDisplayingCell:forRowAtIndexPath: is called for it, then scroll back up until it's shown again. During the scroll up, the tableview is trying to remove the cells that were shown while scrolling down, however its actually removing the wrong cells.
As I'm scrolling up, tableView:didEndDisplayingCell:forRowAtIndexPath: is getting called with the correct index path, one it should be removing, but a cell that corresponds to a different index path. The cell and index path passed to the didEndDisplayingCell don't match.
This is in a small modification of the XLForm example project from https://github.com/xmartlabs/XLForm in which I've added a custom cell. What's weird is that if I make my custom cell the same height as the table's normal height (44) then this doesn't happen. Only when my cell is taller (64, with this value returned from tableView:heightForRowAtIndexPath: and tableView:estimatedHeightForRowAtIndexPath:).
I'm seeing this happen when running in the simulator, iOS versions 8.4 and 9.2.
I haven't been able to figure this out. I don't think I have any of the bugs that have caused others to have disappearing cell syndrome, but even if I do, I don't see how or why the tableview would be calling didEndDisplayingCell with cell and index path that don't match. Does anyone else have a clue what's happening?
I am trying to build a UICollectionView that consists of cells that are of fixed height and varying widths. The cells can either be 100%, 50%, or 25% in width.
I am creating these cells from a custom subclass, and then I am adjusting the size in sizeForIndexPath. My problem is that when reordering cells, I get a lot of weird visual glitches as the cells have their sizes adjusted rapidly as the index path changes.
Basically, I want the size of the cell to depend on the type of cell (or the content in the cell), not the index path of the cell.
What is the best way to handle this? I thought about using multiple classes for the different types of cells, but I can't set the width of the cell with a frame when initializing it. Any ideas?
Update: Here's a link to a video showing the bug I am trying to solve
http://d.pr/v/FTM8+
Try this tutorial. It for a table view but in the conclusion some recomendations for a collection view. I cannot try this tutorial now and garaunted it works for collection view but tomorrow I will do it.
Cheers.
I am having a tableview in which I am displaying my data. As you can assume from the title, these cells are dynamic in their content, and so should their height be. Actually I got it working, but I have a strange issue with the row 0 and 7. These 2 rows take my entire screen, but when I scroll past them and go back again everything is fine. I am not sure but the 7. cell must be among the first cells that are being "dequed" when I scroll down. But as I said, this is just the first time they are being displayed, when I scroll again to one of them, everything is looking good (when filling the tableview with new data it is also fine).
I tried to reload the tableview twice when it is being populated for the first time, but without success. The presentation of the first cell I have fixed calling : self.tableView reloadAtIndexPaths ... when the table is being populated for the first time,
and it worked, it has the height it should have regarding its size. But I still have the issue with cell number 7 (the above fix does not work for this cell, I assume because it is not being displayed at that moment)
I am not using any fancy height calulation, just the iOS 8 feature:
self.tableView.rowHeight = UITableViewAutomaticDimension
self.tableView.estimatedRowHeight = 80
Is there a method, fix with which i can force the tableview to draw the cells again ?
Thanks
Cell size is calculated from constrains. So I assume there is something wrong with those or with data during computation.
try this:
in tableview cell subclass use -prepareForReuse method to clean cell data as before reuse.
I have a UITableView in my app where each UITableViewCell has a custom view added to its contentView. Now, each such custom view can come at any height and I verified that tableView:heightForRowAtIndexPath: returns the correct value. The thing is it used to work just fine prior to iOS7. In iOS7 it cuts off every cell's content at the exact same spot, about 40-50 points from the top. I can see using the table view's separator that each cell has the correct height, so it isn't a matter of the cell going beyond its bounds and being clipped. It is clipped while being contained fully inside the cell's bounds.
Anyone has any idea what is the cause of this issue and how to solve it?
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?)
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.
"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)