In a UITableView
that needs to display a long list of chatlike conversations, often containing emojis, a size calculation error occurs.
My problem is, that if a string is just the right length, and I use sizeWithFont
, I on my first measurement using sizewithfont
get an incorrect length of the string, causing a "linebreak".
I assume that it is because the string ":-)" is broader than the actual smiley icon.
The evidence can be seen here :
Now, over at some other stacks, some claim that sizeWithFont
will only account for the string, not the Emoji, which for me doesn't make sense, since it gets it right "eventually"...
But they propose using sizeToFit instead, so I decided to give it a go.
Bam, same result.
Does anyone know how to counter this ? Is there a boolean
to check if "Label is done being emoji-processed" so i can skip that call ?
Running the same line twice does nothing, it seems the view needs to be drawn, before sizeWithFont
realises its mistake.
The shown column is run in a - (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath
segment, on a custom cell. I can replicate the error on a perfectly regular UITableViewCell as well, so that doesn't seem to be it.
sizeWithFont:constrainedToSize:lineBreakMode
is deprecated and replaced withboundingRectWithSize:options:attributes:context:
– Swinton