With Table view issue in Swift 2.3

[ankushdhawan]

Hello sir

I am using tag list view in the table view. i am calculating the height of cell using UITableViewAutomaticDimension but in the case of tag list view it calculate wrong height . when i scroll down table and scroll up the table view it calculate right height. it works fine ios9 but ios10 it raise the issue

---

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[aaronpearce]

This was fixed in #43 for iOS9 but is back with iOS10. This is not Swift 2.3 specific.

With iOS10, a change has been made as below:

"Sending layoutIfNeeded to a view is not expected to move the view, but in earlier releases, if the view had translatesAutoresizingMaskIntoConstraints set to NO, and if it was being positioned by constraints, layoutIfNeeded would move the view to match the layout engine before sending layout to the subtree. These changes correct this behavior, and the receiver’s position and usually its size won’t be affected by layoutIfNeeded.

Some existing code may be relying on this incorrect behavior that is now corrected. There is no behavior change for binaries linked before iOS 10, but when building on iOS 10 you may need to correct some situations by sending -layoutIfNeeded to a superview of the translatesAutoresizingMaskIntoConstraints view that was the previous receiver, or else positioning and sizing it before (or after, depending on your desired behavior) layoutIfNeeded.

Third party apps with custom UIView subclasses using Auto Layout that override layoutSubviews and dirty layout on self before calling super are at risk of triggering a layout feedback loop when they rebuild on iOS 10. When they are correctly sent subsequent layoutSubviews calls they must be sure to stop dirtying layout on self at some point (note that this call was skipped in release prior to iOS 10)."

This seems to cause the invalidateIntrinsicContentSize (which is missing from the master branch after the merge of Swift 3) to not fire correctly. I added it back to see if that was the cause of the height being incorrect.

Calling the below at the end of rearrangeViews causes the view to layout correctly in height.

invalidateIntrinsicContentSize()
superview?.layoutIfNeeded()

This may not be the optimal solution but it is the one that worked for me.

[ankushdhawan]

its not work in my case

[janandre]

@aaronpearce THANK YOU SO MUCH! Your code snipped is working well! I almost spent hours on this problem, often not knowing what is corrupting the height of some cells. But printing out the intrinsic content size showed me, that the height calculation must be wrong.

I flip out :D

[ankushdhawan]

Hello Sir

Do you find the solution of this issue beacuse its not working well in mycase

[aaronpearce]

Coming back to this, the above fix I posted has failed to work for me in another edge case, but only on 320pt wide devices.

[LittleC]

In my own project, the same issue occurred and was fixed by pre-setting width of TagListView object before layout to some value calculated using constraints and device width began like this. tagListView.frame.size.width = calculatedWidth for it to rearrange tags correctly.

The reason why this happened is that frame size for views inside a table view cell when first initialized from nib could not be relied on before it was actually displayed once. But this library uses frame width to calculate rows of tags in here https://github.com/ElaWorkshop/TagListView/blob/master/TagListView/TagListView.swift#L235

FYI, since iOS10, views inside UITableViewCell or UICollectionViewCell were not sized properly before layout happened. http://stackoverflow.com/questions/39578530/since-xcode-8-and-ios10-views-are-not-sized-properly-on-viewdidlayoutsubviews

[aleene]

See also #88