Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I've add support for rotations but it doesn't play well with
estimatedRowHeight
. I've found that this issue is independant of this implementation, meaning that this happens with cells that have different size depending on rotation and haveestimatedRowHeight
set. The problem is that the table doesn't update the cell's size after rotation so when you scroll you'll see the cells changing its size (bottom up). Still this works great if you avoiding the use ofestimatedRowHeight
, because it ask for the size of all the cells.As an alternative we may calculate both heights (portrait & landscape) at the same time. Then use
tableView:estimatedHeightForRowAtIndexPath:
with that information or the table'sestimatedRowHeight
. The problem there is how to get the cell's width before the rotation occurs.Let me know what do you think.