UICollectionView Different Item Height Issue - ios

Keypoints:
I am using XIB with Autolayout
I am trying to create a UICollectionView that has a dynamic item height. This is needed because I have an UILabel that might have different heights due to it's length. The UILabel's text is set using it's attributedText property
I am aware that:
I MUST NOT implement sizeForItemAtIndexpath.
I MUST set estimatedItemSize to the flowLayout of my UICollectionView.
I have been scavenging Stackoverflow for more than 6 hours but still unable to find solution but most of the solutions are either emphasizing on Storyboards or intended for lower version of iOS.
The best one i have found so far is this UICollectionView Self Sizing Cells with Auto Layout
However, that also did not fix my problem because somehow, my cell does not have the intended width.
Any ideas please?
.
.
Please help me vote this up cause I am literally banging my head now. Any help is very welcome.

Related

Issues setting constraints on UICollectionViewCell

I created an UICollectionViewCell (.xib) and I just wanted to add a label and some simple constraints there, as such:
However, doing this messes up everything. No matter the size I chose on UICollectionViewDelegateFlowLayout, the cell will always use the size of the label! What am I doing wrong here? Am I supposed to not use constraints on CollectionViewItems and instead translatesMaskIntoConstraints = true?
Thanks!
edit: Here's what I expected:
And here's what I actually have (as soon as I add the constraints):
edit2: Fixed! By changing the label's content hugging priority to 10 (for example, or lower). But...why exactly if there are no other constraints in the view? If somebody can answer it, I would be very grateful, cause I could just answer this question and give this solution but I can't explain why exactly it fixed it, so it's not a proper answer anyway.
You have 2 ways: you can delegate to a cell to calculate own height or you can set fixed size for height.
If you want the first case, please, read other related answers
If you want fixed size, you should make a fixed height on the label. Label is calculating own size based on contentSize, so your constraints are failed in the matter of fixed size of your cell

Swift Stevia + UICollectionView self sizing Cells issues

I've spent a few hours figuring out why Stevia and self-sizing cells have terrible sizing issues. It seems that the constraints are conflicting with the auto-sizing. Causing the cell to snap to the wrong size.
So after a lot of trial and error. This is what finally worked.
Set UICollectionViewFlowLayout:estimatedItemSize to UICollectionViewFlowLayout.automaticSize. No other setting seems to work.
Set UICollectionViewCell width and size explicitly to the target cell size.
Do not rely on contentView as your view container. Instead, add a new and also size that view to your target cell size.

UILabel not respecting contraints after scrolling (label inside a xib, dequed as a uitableviewcell)

This is the craziest problem I've ever faced in iOS development. Basically I have a xib file:
This xib file is loaded as a row in a UITableView. In this xib file I have an UILabel ("Texto do comentário"), that is a multiline uilabel and will expand according to its content. To do so, I've added the following constraints and content hugging:
And all this actually works fine when I run and replace the content with a big text. This is how it looks like:
OK, now it begins the weird things, if I scroll up to the other cell (that uses the same xib file), the text view expanded its width and height in a way that doesn't respect my constraints:
Now if I scroll back to my cell that was working fine before, it has the same problem, the uilabel's width and height are not respecting my constraints anymore:
I've tried to inspect what actually happens to the constraints, if they are being ignored by some reason, and here is what I've found out. Both the constraints of my uilabel that has the right size and the ones in the uilabel that has the wrong size are the same.
I'm really starting to thing that this an iOS bug. Thank you in advance for your help
After trying, at least everything. The fix I found is to use UITextView instead of UILabel. This fix made me be sure that this is a UILabel bug.
I would say the problem you have is that you changes the Content Hugging Priority and Content Compression Resistance Priority values, which will make the UILabel not resize as you would expect.
You could try resetting the values to the default ones and if your other constraints are correct, the height of the label and of the cell should be calculated correctly.
Probably the UITextView worked because you did not change the default values for these properties.
Hope this helps.
This looks like another bug I previously encountered with self-sizing cells in a table view. Originally, I worked around it by explicitly setting the preferredMaxLayoutWidth of my cell's labels but I then discovered that sending an -updateConstraintsIfNeeded message to my cell in -tableView:cellForRowAtIndexPath: also worked around the issue without needing to set the preferredMaxLayoutWidth.
Hope this helps.

Swift, dynamic table view cell heights using Storyboards

I've been wrestling with this for a better part of a week and I'd love some help.
I have a cell laid out in storyboards that's a subclass of UITableViewCell called EntryCell. I've been using autolayout to set constraints in storyboards and all of the constraints on all the elements are blue, lldb throws no errors at runtime so nothing is duplicated or out of place.
My label that says "Journal Entry Here" below is a UILabel and has lines set to 0.
In my view controller under ViewDidLoad, I have
tableView.estimatedRowHeight = 185
tableView.rowHeight = UITableViewAutomaticDimension
but when I run that, simulator shows this:
This is holding up my entire project. I've read a number of tutorials and tried their implementations to no avail. I'm currently not doing anything with heightForRowAtIndexPath. I wonder if that's the problem or if it's something else.
Any help would be hugely appreciated. Thank you!
You shouldn't have to use heightForRowAtIndexPath to get this to work. The main reason UITableViewAutomaticDimension won't expand to fit unlimited line labels is because of missing layout constraints--constraints that won't necessarily show up in the console as errors. There must be continuous anchoring for every UI Object from the top to the bottom and to the left and right of your cell for expansion to work properly. If you think you've taken care of this and the cell still doesn't expand, try posting a screen shot and list of your layout constraints so we can review.

UITableViewCell wrong height in initial display

This isn'an a question, just a results log on an issue I had with XCode 4.5 storyboards and dynamic height UITableCell with a UILabel.
The issue was; the initial display of a cell would only show part of the resized UILabel contents, and that the visual UILabel was not resized. It would only display correctly after scrolling off the top of the Table and back down.
I did the calculations in hieghtForRowAtIndexPath and sizeToFit the UILabel in rowAtIndexPath. The sizes where coming up ok in debug, but the device was not updating the display with the correct size and UILable.text value.
I had created the dynamic UITableCell in a storyboard. However, I had set the width and height to a nominal value (290x44). It turns out, this was causing my issues.
I set the width and height to zero (0) in the story board, and everything started working correctly. (i.e. the UILabels displayed at the correct size with full content).
I was unable to find anything online on this issue, except for some references to creating the custom table cell with a frame of zero. Turns out, that was really the answer (for me).
I ran into the same problem and solved it by simply unchecking "Use Autolayout" in storyboard. You might want to give it a try.
I was unable to find anything online on this issue, except for some references to creating the custom table cell with a frame of zero. Turns out, that was really the answer (for me).

Resources