I need pretty simple thing - table cells which automatically detect their own height. There are a lot of examples out there, which basically say "set couple of flags and values on your table and use autolayout in your cell". My case is a bit special - I load the content of the cell from a separate XIB file which is a plain UIView. The first problem comes already when I create that XIB file in interface builder - I don't know how to make it's height to "calculate" according to constraints that I specify. I am always getting IB errors unless I switch to "Freeform" and resize the view to the height matching my constraints. If I don't do that, I will get the following errors:
In the above example I just need a view which height will be 32 (image height) + 2 * 16 (vertical distance constraints of image from parent's top and bottom) plus the margins. Resizing the freeform view in IB until the errors disappear seems like a dirty hack to me, and it is actually not autolayout. As a next step, I define a cell class, where I put this xib view, something like this (sorry for objc code, almost done porting the project to swift):
- (void)awakeFromNib {
[super awakeFromNib];
[[NSBundle mainBundle] loadNibNamed:#"CellContent" owner:self options:nil];
// self.content is an outlet which gets the root of the XIB on load
[self.contentView addSubview:self.content];
self.contentView.translatesAutoresizingMaskIntoConstraints = NO;
[self.contentView.leftAnchor constraintEqualToAnchor:self.content.leftAnchor].active = YES;
[self.contentView.rightAnchor constraintEqualToAnchor:self.content.rightAnchor].active = YES;
[self.contentView.topAnchor constraintEqualToAnchor:self.content.topAnchor].active = YES;
[self.contentView.bottomAnchor constraintEqualToAnchor:self.content.bottomAnchor].active = YES;
}
As you might guess, when I run this the cell height is the big freeform one, like in the IB of the content XIB, so no auto layout. It seems like the freeform height is even added as another constraint and there is a constraint conflict which results in some of them being broken at runtime.
Let me know how can I fix this, easily create content views for my cells which have auto heights and which I can embed in my cells to benefit the tableView.rowHeight = UITableViewAutomaticDimension magic?
Maybe you forgot to set the Content Hugging Priority and Content Compression Resistence Priority of the Labels.enter image description here
I found what was my problem. Actually, there were conflicts with constraints added because of autoresizing. So I changed this line (from the question above):
self.contentView.translatesAutoresizingMaskIntoConstraints = NO;
to:
self.content.translatesAutoresizingMaskIntoConstraints = NO;
Stupid mistake, the translatesAutoresizingMaskIntoConstraints flag should be disabled for the child view after adding, not for the parent view, as I incorrectly did. After that the magic with cell auto height detection started working like charm.
Make sure UILabel has multiline property . So , Set 0 for Line Property at Attribute Inspector .
Make sure that UILabel Auto-Layout is properly relative to Left-Right-Top-Bottom .
Apply these delegate Functions :
-(CGFloat) tableView:(UITableView *)tableView estimatedHeightForRowAtIndexPath:(NSIndexPath *)indexPath
{
return UITableViewAutomaticDimension;
}
-(CGFloat)tableView:(UITableView *)tableView heightForRowAtIndexPath:(NSIndexPath *)indexPath
{
return UITableViewAutomaticDimension;
}
Related
I created a dynamic cell using AutoLayout, put code in (void)updateConstraints cell's subview method, set BOOL value so custom AutoLayout code runs only once, and in View Controller call
[cell setNeedsUpdateConstraints];
[cell updateConstraintsIfNeeded];
just before returning cell. Everything seems to works fine but I'm experiencing weird issue, when I select cell all its subviews (or itself?) change position.
cell pointed with this beautiful arrow shows it ;]
I experienced the same bug and tinkered for about a day to fix this ... to get to the bottom of the issue I set different background colors on the cell & the content view. Right after first showing the table view everything seemed to work, but after selecting the cell the contentView would jump around - sometimes when selecting, sometimes when deselecting (which I do immediately in tableView:didSelectRowAtIndexPath:), and the cell's background became visible. So I figured the cell somehow didn't reestablish the correct contentView dimensions.
Finally it turned out that at least in iOS 8 you need to set the appropriate autoresizingMasks for the cell as well as the contentView, and then make the layout system translate them into constraints by setting translatesAutoresizingMaskIntoConstraints to YES. At the same time this flag needs to be NO on all subviews of your contentView.
So here's my initialisation for custom cells:
- (void)awakeFromNib {
// enable auto-resizing contentView
[self setTranslatesAutoresizingMaskIntoConstraints:YES];
[self.contentView setTranslatesAutoresizingMaskIntoConstraints:YES];
self.autoresizingMask = UIViewAutoresizingFlexibleHeight | UIViewAutoresizingFlexibleWidth;
self.contentView.autoresizingMask = UIViewAutoresizingFlexibleHeight | UIViewAutoresizingFlexibleWidth;
// remove autoresizing constraints from subviews
for (UIView *view in [self.contentView subviews]) {
view.translatesAutoresizingMaskIntoConstraints = NO;
}
}
Works like a charm for me. For the record, I'm using the UITableViewCell auto-sizing which was introduced in iOS 8, like this:
// enable automatic row heights in your UITableViewController subclass
self.tableView.rowHeight = UITableViewAutomaticDimension;
self.tableView.estimatedRowHeight = 80.0; // set to whatever your "average" cell height is
I found solution to this issue,I used instructions under this link dynamic-cell-layouts-variable-row-heights to implement dynamic table view cells: [Using Auto Layout in UITableView for dynamic cell layouts & variable row heights
[1]: Using Auto Layout in UITableView for dynamic cell layouts & variable row heights. Author suggests to use this two methods to update constrains when using updateConstraints method inside cell's subview.
[cell setNeedsUpdateConstraints];
[cell updateConstraintsIfNeeded];
but what I found in my case is there was some issue that not all cells was updated as they should. Solution is to call [cell updateConstraints] in (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath and not wait until system will update constrains.
There's more content in my Table View, but this cell is getting cut off and not showing more content:
... So I'm not able to scroll any more, even there is more content.
If I pull up with my finger it shows more content, but then when I let my finger off the cell it goes back to the state show in the image above.
I've tried making sure I set height and width in the Labels and Images in AutoLayout since I thought that might be a problem, but still hasn't fixed it.
Any ideas? Thanks!
UPDATE - Table View structure in Storyboard
- (CGFloat) tableView:(UITableView *)tableView heightForRowAtIndexPath:(NSIndexPath *)indexPath {
id model = self.model[indexPath.row];
if ([model isKindOfClass:[DBase self]]) {
return 520;
}
else {
return tableView.rowHeight; // return the default height
}
}
I was having this problem as well but mine was only cutting off a single cell. I solved it and thought I'd post this here as it may help others in the future
I was using custom cells created from nibs. Some of my cells could change heights so I was also using this:
tableView.rowHeight = UITableViewAutomaticDimension
tableView.estimatedRowHeight = 61
I figured out the issue was that I was setting top, left, right and height constraints on my view. I needed to set the bottom constraint as well or else my row height would be way smaller than it should be.
So if you are having this problem check if your row heights aren't smaller than the views that they contain.
I suggest adding height and width constraints to your UITableViewContoller or UITableView in the storyboard.main.
Depending on the size of your device, the UITableView size will remain constant unless you set constraints that will work across all devices.
I'm using Apple's DateCell sample Xcode project to figure out how to use a UIPickerView inside of a UITableViewCell, but I'm having some trouble figuring out the constraints that the sample code has set up for the UIDatePicker in the storyboard.
Link: https://developer.apple.com/library/ios/samplecode/DateCell/Introduction/Intro.html
It says that the UIDatePicker has a constraint relative to the actual UITableViewCell, but when I try to set up a constraint between the two, I can't. Ctrl-dragging from the picker to the cell doesn't highlight the cell. I tried doing it with the cell's content view rather than the cell itself, but that doesn't quite produce the same result as in the sample code's storyboard.
These are the constraints set up by the project for the date picker:
And for the cell:
What the sample's storyboard looks like:
How can I reproduce the above image using constraints?
Any help would be greatly appreciated.
I found that the sample's static height was not what I wanted to use anyway, since I have some cells with lots of text that need to have variable heights for each cell. So instead of the approach in the sample which grabs the height of the picker cell from the pre-defined storyboard size, I used UITableViewAutomaticDimension to automatically fit all of my cells for height. If you don't want auto height, it's still pretty easy to adapt the following solution to set the height to a static value, as I mention in step 3.
Set tableview row height to auto when the view loads:
- (void)viewWillAppear:(BOOL)animated {
[super viewWillAppear:animated];
self.tableView.estimatedRowHeight = 60.0; // Set your average height here.
self.tableView.rowHeight = UITableViewAutomaticDimension;
}
Add an estimated height so that it works properly (at least in iOS 8). If you don't add this, you might get some buggy behavior when it draws the cell heights.
- (CGFloat)tableView:(UITableView *)tableView estimatedHeightForRowAtIndexPath:(NSIndexPath *)indexPath {
return UITableViewAutomaticDimension;
}
For auto height, remember to remove the tableView:heightForRowAtIndexPath: definition if you have one, as it could interfere with the auto settings.
// Don't define this at all if you want the picker cell to have auto height.
//- (CGFloat)tableView:(UITableView *)tableView heightForRowAtIndexPath:(NSIndexPath *)indexPath
//{ }
If you want to use a static height for the picker cell, then define the tableView:heightForRowAtIndexPath: function and just return the static value here instead of using the auto dimension like the sample does it. Example would be something like this:
- (CGFloat)tableView:(UITableView *)tableView heightForRowAtIndexPath:(NSIndexPath *)indexPath
{
// This would return the static height for the picker, but auto heights for the rest of the cells.
return ([self indexPathHasPicker:indexPath] ? self.pickerCellRowHeight : UITableViewCellAutoDimension);
}
And then you'd modify the sample to set your static height instead of grabbing it from the frame value in viewDidLoad.
// obtain the picker view cell's height, works because the cell was pre-defined in our storyboard
//UITableViewCell *pickerViewCellToCheck = [self.tableView dequeueReusableCellWithIdentifier:kDatePickerID];
self.pickerCellRowHeight = 216;//CGRectGetHeight(pickerViewCellToCheck.frame);
Rather than trying to recreate the same constraints from the sample, I told storyboard to Reset to Suggested Constraints for the UIPickerView, and then added one more. It added the first two in the picture, and then I just added one more for aligning the center X. My view happened to have the shown numbers from the auto settings but yours may be different.
In case you haven't already done it, part of making the picker work is to make sure the dataSource and delegate for the UIPickerView are set to the view controller using storyboard and control clicking and dragging.
The Goal
I'm trying to create a dynamic message cell using auto-layout.
What I've Tried
The cell is positioning correctly, for the most part, with auto-layout given the following constraints:
The Problem
My first problem was the message label (Copyable Label) width was constrained. That seems to be resolved by using setPreferredMaxLayoutWidth: as described in this question.
Height is still a problem. As you can see, the message bubble is still cutting off. In addition, I'm not sure how to determine the message cell height for the table view.
I expected auto-layout to somehow just work. I've read the answer here, but it seems like a lot to of steps.
The Question
First, is a case where auto-layout is more complex than traditional frame arithmetic?
Second, using auto-layout, how can I determine the height of the resulting cell?
I fully use Auto Layout and what you speak about is kinda a problem.
I didn't want to modify the way intrinsic size is calculated for performance purpose of UITable.
So I used a very simple way that is correct in the end. It's ok if your cell is simple, can become such hard if your cell contains more than one variable text.
I defined my cells normally, where you can put a UILabel that fits the insets (no problem about it).
Then, in your table datasource, you define directly the height of the cell:
- (CGFloat)tableView:(UITableView *)tableView heightForRowAtIndexPath:(NSIndexPath *)indexPath {
return [TEXTOFYOURCELL sizeWithFont:[UIFont systemFontOfSize:14] constrainedToSize:CGSizeMake(300, 1000)].height + 31; // Here it's defined for 15 of top and bottom insets, define +1 than the size of the cell is important.
}
EDIT :
Here some code about the UILabel in the cell (in init method).
__titleLabel = [UILabel new];
__titleLabel.numberOfLines = 0;
[self.contentView addSubview:__titleLabel]; // adding to contentView rather than self is very important !
[__titleLabel keepInsets:UIEdgeInsetsMake(0, 15, 0, 15)];
I use this API : https://github.com/iMartinKiss/KeepLayout to manage auto layout simpler.
This is possible on iOS 8 as can be read on AppCoda
Basically:
Set the label lines to 0.
Set the row height UITableViewAutomaticDimension
I have a uilabel setup in a view. It doesn't have a width constraint, but its width is instead determined by a leading constraint to the thumbnail image, and a trailing constraint to the edge of the view.
The label is set to have 0 lines, and to word wrap. My understanding is that this should cause the frame of the uilabel to grow, and indeed it does sometimes. (Previous to auto layout, I would calculate and update the frame of the label in code).
So the result is, it works correctly in some instance and not others. See most cells working correctly there, but the last cell appears to be too big. In fact it's the right size. The title "Fair Oaks Smog Check Test" actually ends with "Only". So my calcuation for the cell size is right, it should be that size. However the label doesn't wrap the text for whatever reason. It's frame width does not extend off to the right, so that's not the issue.
So what is going on here? It's 100% consistent, always on that cell and not the ones above it, which makes me think it's related to the size of the text, and UILabel isn't re-laying out the text once this view is added to the cell (which makes it actually smaller width wise).
Any thoughts?
Some additional information
The height of the cells is calculated from one sample cell I create and store in a static variable:
- (CGFloat) tableView:(UITableView *)tableView heightForRowAtIndexPath:(NSIndexPath *)indexPath {
if (self.items.count == 0) {
return 60;
}
static TCAnswerBuilderCell *cell = nil;
static dispatch_once_t pred;
dispatch_once(&pred,
^{
// get a sample cellonce
cell = [tableView dequeueReusableCellWithIdentifier:TC_ANSWER_BUILDER_CELL];
});
[cell configureCellWithThirdPartyObject:self.items[indexPath.row]];
return [cell heightForCellWithTableWidth:self.tableView.frame.size.width];
}
I configure the cell with my data object on the fly, and then call a method I have on it which calculates the height of the cell with a given table width (can't always rely on the cell frame being correct initially).
This in turn calls a height method on my view, since it is really where the label lives:
- (CGFloat)heightForCellWithTableWidth:(CGFloat)tableWidth {
// subtract 38 from the constraint above
return [self.thirdPartyAnswerView heightForViewWithViewWidth:tableWidth - 38];
}
This method determines the height by figuring out the correct width of the label, and then doing a calculation:
- (CGFloat)heightForViewWithViewWidth:(CGFloat)viewWidth {
CGFloat widthForCalc = viewWidth - self.imageFrameLeadingSpaceConstraint.constant - self.thumbnailFrameWidthConstraint.constant - self.titleLabelLeadingSpaceConstraint.constant;
CGSize size = [self.titleLabel.text sizeWithFont:self.titleLabel.font constrainedToSize:CGSizeMake(widthForCalc, CGFLOAT_MAX) lineBreakMode:NSLineBreakByWordWrapping];
CGFloat returnHeight = self.frame.size.height - self.titleLabel.frame.size.height + size.height;
CGFloat height = returnHeight < self.frame.size.height ? self.frame.size.height : returnHeight;
return height;
}
This works 100% correctly.
The cells are created obviously in cellForRowAtIndexPath and immediately configured:
if (self.items.count > 0) {
TCAnswerBuilderCell *cell = [tableView dequeueReusableCellWithIdentifier:TC_ANSWER_BUILDER_CELL forIndexPath:indexPath];
[cell configureCellWithThirdPartyObject:self.items[indexPath.row]];
return cell;
}
In configuration of the cell, my view is loaded from a nib (it's re-used elsewhere, which is why it's not directly in the cell). The cell adds it as follows:
- (void) configureCellWithThirdPartyObject:(TCThirdPartyObject *)object {
self.detailDisclosureImageView.hidden = NO;
if (!self.thirdPartyAnswerView) {
self.thirdPartyAnswerView = [TCThirdPartyAPIHelper thirdPartyAnswerViewForThirdPartyAPIServiceType:object.thirdPartyAPIType];
self.thirdPartyAnswerView.translatesAutoresizingMaskIntoConstraints = NO;
[self.contentView addSubview:self.thirdPartyAnswerView];
[self.contentView addConstraints:[NSLayoutConstraint constraintsWithVisualFormat:#"|[_thirdPartyAnswerView]-38-|" options:NSLayoutFormatAlignAllCenterY metrics:nil views:NSDictionaryOfVariableBindings(_thirdPartyAnswerView)]];
}
[self.thirdPartyAnswerView configureViewForThirdPartyObject:object forViewStyle:TCThirdPartyAnswerViewStyleSearchCell];
}
Finally my view configuration looks like this:
- (void) configureViewForThirdPartyObject:(TCTPOPlace *)object forViewStyle:(TCThirdPartyAnswerViewStyle) style {
self.titleLabel.text = object.name;
self.addressLabel.text = [NSString stringWithFormat:#"%#, %#, %#", object.address, object.city, object.state];
self.ratingsLabel.text = [NSString stringWithFormat:#"%d Ratings", object.reviewCount];
NSString *ratingImageName = [NSString stringWithFormat:#"yelp_star_rating_%.1f.png", object.rating];
UIImage *ratingsImage = [UIImage imageNamed:ratingImageName];
if (ratingsImage) {
self.ratingImageView.image = ratingsImage;
}
if (object.imageUrl) {
[self.thumbnailImageView setImageWithURL:[NSURL URLWithString:object.imageUrl] completed:nil];
}
}
A sort of solution, but I don't understand why
My subview was designed at 320 width, but has no constraints of its own for width
The subview was added to the cell, but with horizontal constraints that look like this:
#"|[_thirdPartyAnswerView]-38-|"
The view was configured immediately after being added to the cell, meaning the text for the titleLabel was set right then.
For whatever reason, the text was laid out as if the view had the full 320 instead of 282.
The label was never updated, even though the frame of the subview was updated to 282, and there were constraints on the label that would keep it sized correctly.
Changing the size of the view in the xib to be 282 fixed the issue, because the label has the right size to begin with.
I'm still not understanding why the label doesn't re-lay out after the size of the parent view is updated when it has both leading and trailing constraints.
SOLVED
See Matt's answer below: https://stackoverflow.com/a/15514707/287403
In case you don't read the comment, the primary problem was that I was unknowingly setting preferredMaxLayoutWidth via IB when designing a view at a bigger width than it would be shown (in some cases). preferredMaxLayoutWidth is what is used to determine where the text wraps. So even though my view and titleLabel correctly resized, the preferredMaxLayoutWidth was still at the old value, and causing wrapping at unexpected points. Setting the titleLabel instead to it's automatic size (⌘= in IB), and updating the preferredMaxLayoutWidth dynamically in layoutSubviews before calling super was the key. Thanks Matt!
I'm someone who has written an app that uses autolayout of five labels in a cell in a table whose cells have different heights, where the labels resize themselves according to what's in them, and it does work. I'm going to suggest, therefore, that the reason you're having trouble might be that your constraints are under-determining the layout - that is, that you've got ambiguous layout for the elements of the cell. I can't test that hypothesis because I can't see your constraints. But you can easily check (I think) by using po [[UIWindow keyWindow] _autolayoutTrace] when paused in the debugger.
Also I have one other suggestion (sorry to just throw stuff at you): make sure you're setting the label's preferredMaxLayoutWidth. This is crucial because it's the width at which the label will stop growing horizontally and start growing vertically.
I had the same problem and solved it using a suggestion from this answer. In a subclass of UILabel I placed this code:
- (void)layoutSubviews
{
[super layoutSubviews];
self.preferredMaxLayoutWidth = self.bounds.size.width;
}
I don't understand why this is not the default behavior of UILabel, or at least why you cannot just enable this behavior via a flag.
I am a little concerned that preferredMaxLayoutWidth is being set in the middle of the layout process, but I see no easy way around that.
Also, check that you are passing integral numbers to your layout constraints in code.
For me it happened that after some calculations (e.g. convertPoint:toView:), I was passing in something like 23.99999997, and eventually this lead to a 2-line label displaying as a one-liner (although its frame seemed to be calculated correctly). In my case CGRectIntegral did the trick!
Rounding errors could kill ya :)