The iOS 7 redesign resulted in change of the view hierarchy of UITableViewCells. The content view of the cell was wrapped in a private class called UITableViewCellScrollView.
In iOS 7 UITableViewCellScrollView has clipsToBounds set to YES and UITableViewCellContentView has clipToBounds set to NO.
In iOS 7.1 UITableViewCellScrollView has clipsToBounds set to NO and UITableViewCellContentView has clipToBounds set to NO.
If you call [[self contentView] setClipsToBounds:YES] in iOS 7.1 is does it stick. By the time layoutSubviews is called on the cell UITableViewCellContentView has clipToBounds set to NO again.
[[self contentView] superview] setClipsToBounds:YES] works in iOS 7.1 and sets UITableViewCellScrollView's clipToBounds to YES but this is a very brittle solution.
Overriding layoutSubview on the cell and calling [[self contentView] setClipsToBounds:YES] works but is another fraile solution.
Does anyone know why this change has been made and a more robust solution to it?
As discussed in the comments, the only solution right now in iOS7.1 is to set clipsToBounds on the cell itself.
It's quite annoying. What I did is add an UIView in the contentView with identical size (and autoresizingMask in width), add the relevant content to this view, and set clipsToBounds to it.
I hit the some problem, and I solved this confused problem by an ugly way finally.
// Create a subclass of UITableView
// Then override setClipsToBounds:
- (void)setClipsToBounds:(BOOL)clipsToBounds {
[super setClipsToBounds:YES];
}
In iOS 8, checking the cell's "Clip Subviews" in the XIB did not work.
What does work is:
- (void)awakeFromNib {
[super awakeFromNib];
// Initialization code
self.clipsToBounds = YES;
}
Related
I'm creating my UI entirely in code and using Masonry to constrain the cell's content view's subviews to the appropriate height. I'm using
[cell.contentView systemLayoutSizeFittingSize:UILayoutFittingCompressedSize].height
on iOS 7 for the row height, while iOS 8 handles it automatically.
Everything looks exactly as it should on screen, but in the console I get trainloads of warnings for conflicting constraints, which all seem to be caused by an unasked and unnecessary height constraint on the cell's content view (e.g. <NSLayoutConstraint UITableViewCellContentView.height == 44>).
On iOS 8 I'm setting the table view's rowHeight as UITableViewAutomaticDimension (effectively -1) but still I get this constraint. I'm only adding constraints between the content view and its own subviews, so no constraints between the content view and the cell itself.
Any idea where this constraint comes from and how to make it go away?
Edit: Now I actually found a "solution" of sorts – initially setting the content view's frame to something ridiculous, like CGRectMake(0, 0, 99999, 99999), before adding subviews or constraints, seems to make the warnings go away. But this doesn't exactly smell like the right way to do it, so can anyone tell of a better approach?
I had the same issue and fixed it setting the auto resizing mask of the cell like this:
override func awakeFromNib() {
super.awakeFromNib()
self.contentView.autoresizingMask = .flexibleHeight
}
Also in the controller I set the estimated height and tell the table view to use automatic dimension (in the viewDidLoad method:
self.tableView.estimatedRowHeight = 120
self.tableView.rowHeight = UITableView.automaticDimension
These links helped:
http://useyourloaf.com/blog/2014/08/07/self-sizing-table-view-cells.html
Auto layout constraints issue on iOS7 in UITableViewCell
Hope this helps!
To tack on to the accept answer- after months of trying to get iOS 8's automatic cell sizing to work I discovered an important caveat. The 'estimatedRowHeight' property MUST be set. Either via the tableView directly or by implementing the delegate methods. Even if there's no way to determine a valid estimate, simply providing a value other than the default (0.0) has demonstrably allowed iOS 8's cell layout to work in my testing.
Regarding to the "solution" mentioned in the edit in the question (setting the contentView frame to something big temporarily), here's proof this is a good "solution":
https://github.com/smileyborg/TableViewCellWithAutoLayoutiOS8/blob/master/TableViewCellWithAutoLayout/TableViewController/TableViewCell.swift
// Note: if the constraints you add below require a larger cell size than the current size (which is likely to be the default size {320, 44}), you'll get an exception.
// As a fix, you can temporarily increase the size of the cell's contentView so that this does not occur using code similar to the line below.
// See here for further discussion: https://github.com/Alex311/TableCellWithAutoLayout/commit/bde387b27e33605eeac3465475d2f2ff9775f163#commitcomment-4633188
// contentView.bounds = CGRect(x: 0.0, y: 0.0, width: 99999.0, height: 99999.0)
It's hacky but it seems to work.
- (instancetype)initWithStyle:(UITableViewCellStyle)style reuseIdentifier:(NSString *)reuseIdentifier {
if (self = [super initWithStyle:style reuseIdentifier:reuseIdentifier]) {
//self.contentView.translatesAutoresizingMaskIntoConstraints = NO;
self.contentView.autoresizingMask = UIViewAutoresizingFlexibleHeight;
self.itemView = [CustomItemView new];
[self.contentView addSubview:self.itemView];
}
return self;
}
set translatesAutoresizingMaskIntoConstraints to NO is not work for me
, but autoresizingMask = UIViewAutoresizingFlexibleHeight is well.
you should also making constraints like this:
- (void)updateConstraints {
[self.itemView mas_updateConstraints:^(MASConstraintMaker *make) {
make.leading.trailing.top.equalTo(0);
//make.bottom.equalTo(0);
make.bottom.lessThanOrEqualTo(0);
}];
[super updateConstraints];
}
bottom constraints not just equalTo contentView's bottom, you should use lessThanOrEqualTo
hope this is work to you!
I found out that in some cases, setting an estimatedHeight that is many times bigger the height of my average cell fixed most if not all warnings and had no negative impact on the display.
i.e.:
Setting self.tableView.estimatedRowHeight = 500.0f while most rows are only about 100.0f in height fixed my issue.
since new Xcode 6 came, I struggle with some problem. I can't resize the frame of inputAccessoryView.
I use custom inputAccessoryView (resizable) for UITextField, which has as a subview UITextview. To resize content, I used to change the frame of accessoryView, and it worked. Now it has always the same init size.
Everything works perfect on previous iOS 7.
frist, get inputAccessoryView and set nil
UIView *inputAccessoryView = yourTextView.inputAccessoryView;
yourTextView.inputAccessoryView = nil;
[yourTextView reloadInputViews];
then set frame and layout
inputAccessoryView.frame = XXX
[inputAccessoryView setNeedsLayout];
[inputAccessoryView layoutIfNeeded];
last set new inputAccessoryView and reload
yourTextView.inputAccessoryView = inputAccessoryView;
[yourTextView reloadInputViews];
I have created this simple custom UIView
- (id)initWithCoder:(NSCoder *)aDecoder
{
self = [super initWithCoder:aDecoder];
if (self) {
internalView = [UIView new];
[self addSubview:internalView];
internalView.backgroundColor = [UIColor whiteColor];
sublabel = [UILabel new];
sublabel.text = #"test";
sublabel.backgroundColor = [[UIColor yellowColor] colorWithAlphaComponent:0.4];
sublabel.textAlignment = NSTextAlignmentCenter;
sublabel.translatesAutoresizingMaskIntoConstraints = NO;
[internalView addSubview:sublabel];
}
return self;
}
- (void)layoutSubviews
{
[super layoutSubviews];
[internalView setFrame:self.bounds];
[sublabel setFrame:internalView.bounds];
}
#end
The view is used in a xib where are defined 4 constraints:
The constrains are related to the top, trailing, leading and the height.
The views hierarchy of the custom view is self -> internalView -> sublabel
The layoutSubviews is doing a simple thing like setting the frame of each subview with the bounds of the superview.
I created the code above just to point out a strange behaviour i found in translatesAutoresizingMaskIntoConstraints.
(The yellow view is the label)
If the value of the property is YES the results is what I expect from the code in the layoutSubviews method
If it is NO, with the same layoutSubviews i got:
The documentation of the translatesAutoresizingMaskIntoConstraints says:
If this is value is YES, the view’s superview looks at the view’s
autoresizing mask, produces constraints that implement it, and adds
those constraints to itself (the superview).
In both cases the autoresizingMask is set to UIViewAutoresizingNone and there are no constraints in the constraints property of the label.
Why with the translatesAutoresizingMaskIntoConstraints=NO the frame that i set in the layoutSubviews is not what i see on screen?
Edit 2:
I expect, given the exposed scenario, to have the same results with translatesAutoresizingMaskIntoConstraints set to YES or NO.
Edit:
I tried to swizzle the sizeToFit method to check if it is called. It's not.
This is happen in iOS6/7
Update 08/08/14
After further investigation i discovered that there is a way to change the frame of the label without having autolayout playing around.
I discovered that after the first pass of layout (when is called the layoutSubviews) with the translatesAutoresizingMaskIntoConstraints=NO autolayout adds constraints for the hugging/compression of the UILabel. The point is that for every view that implements intrinsicContentSize returning something different from UIViewNoIntrinsicMetric the autolayout adds specific constrains. That is the reason behind the resizing of the label.
So the first thing that i did is to reimplement a subclass of the UILabel to override the
intrinsicContentSize.
After that, following the suggestions in this really good article http://www.objc.io/issue-3/advanced-auto-layout-toolbox.html, I tried to turn of autolayout completely for the subviews involved removing [super layoutSubviews].
The goal for me was to avoid that autolayout could act on views where a was trying to apply animated transformations. So if you have the same needs i hope this can help you.
This comes more from intuition of having used it than actual study, but...
If you set translatesAutoresizingMaskIntoConstraints to YES, the system will create constraints to enforce the frame you defined for your view.
If it is set to NO, no constraints will be set for the view, and as you did not set them yourself either, the view will be resized according to default behaviours. In this case it seems to resize to the minimum content size because of the "contentHugging" values.
Bottom line is, from my understanding, when auto-layout is active all views need constraints to be properly placed. You either set that property to YES, or set the constraints yourself. If you don't do either, results will be a bit unpredictable.
The UIViewAutoresizingNone mask is still a valid mask, with fixed dimensions (no resizing) and it will be translated to constraints. Views can coexist without setting constraints, when you set that option to YES.
You are interpreting UIViewAutoresizingNone as meaning "no mask" when it really means "mask with no resizing". Sorry to disagree with you, but I think that this is the expected behaviour :)
Since iOS 8 [UIColletionViewCell systemLayoutSizeFittingSize:UILayoutFittingCompressedSize] returns a size with height of 0.
Here's what the code does:
To determine the size for cell in a UICollectionView in iOS 7 I use systemLayoutSizeFittingSize: on a cell defined in a xib file using auto layout. The size depends on the font size of an UILabel being a subview of the UICollectionViewCell in my xib file. The label's font is set to UIFontTextStyleBody. So basically the cell's size depends on the font size setting made in iOS 7.
Here is the code itself:
+ (CGSize)cellSize {
UINib *nib = [UINib nibWithNibName:NSStringFromClass([MyCollectionViewCell class]) bundle:nil];
// Assumption: The XIB file only contains a single root UIView.
UIView *rootView = [[nib instantiateWithOwner:nil options:nil] lastObject];
if ([rootView isKindOfClass:[MyCollectionViewCell class]]) {
MyCollectionViewCell *sampleCell = (MyCollectionViewCell*)rootView;
sampleCell.label.text = #"foo"; // sample text without bar
[sampleCell setNeedsLayout];
[sampleCell layoutIfNeeded];
return [sampleCell systemLayoutSizeFittingSize:UILayoutFittingCompressedSize];
}
return CGSizeZero;
}
It works perfectly fine in iOS 7 but not in iOS 8. Unfortunately I have no clue why.
How can I get the auto layout size of the UICollectionViewCells in iOS 8?
PS: Using
return [sampleCell.contentView systemLayoutSizeFittingSize:UILayoutFittingCompressedSize];
instead of
return [sampleCell systemLayoutSizeFittingSize:UILayoutFittingCompressedSize];
as somebody might suggest, doesn't make any difference.
What you need to do is wrap all of your content in a container view, then call:
return [sampleCell.containerView systemLayoutSizeFittingSize:UILayoutFittingCompressedSize];
Your cell should look like this: cell -> containerView -> sub views
This works on both ios7 & ios8.
Supposedly on ios8, all you have to do is set the estimateSize & cell will automatically auto size on its own. Apparently that's not working as of beta 6.
Looks like this officially a bug: I filed a report that was closed as a duplicate of this one
Will report back when Beta 6 is out.
[Update: working properly in the GM seed of iOS 8, and the bug has been closed by Apple.]
We're using a work-around for now, copied below. Hopefully, these issues will be resolved before iOS 8 release and we can remove this. (The kludge assumes knowledge of Apple's implicit contentView behavior, and we have to hack IB outlet references to any constraints we transfer.)
We notice they're also removing all autoresizingMasks from storyboards/NIBs during upgrade, which makes sense given it's supposed to be auto-layout, but collection views still throwback to springs & struts. Perhaps this has been overlooked in the purge?
--Dan
/**
Kludge around cell sizing issues for iOS 8 and deployment to iOS 7 when compiled for 8. Call this on the collection view cell before it is used, such as in awakeFromNib. Because this manipulates top-level constraints, any references to such initial constraints, such as from IB outlets, will be invalidated.
Issue 1: As of iOS 8 Beta 5, systemLayoutSizeFittingSize returns height 0 for a UICollectionViewCell. In IB, cells have an implicit contentView, below which views placed in IB as subviews of the cell are actually placed. However, constraints set between these subviews and its superview are placed on the cell, rather than the contentView (which is their actual superview). This should be OK, as a constraint among items may be placed on any common ancestor of those items, but this is not playing nice with systemLayoutSizeFittingSize. Transferring those constraints to be on the contentView seems to fix the issue.
Issue 2: In iOS 7, prior to compiling against iOS 8, the resizing mask of the content view was being set by iOS to width+height. When running on iOS 7 compiled against iOS 8 Beta 5, the resizing mask is None, resulting in constraints effecting springs for the right/bottom margins. Though this starts out the contentView the same size as the cell, changing the cell size, as we do in the revealing list, is not tracked by changing it's content view. Restore the previous behavior.
Moving to dynamic cell sizing in iOS 8 may circumvent this issue, but that remedy isn't available in iOS 7.
*/
+ (void)kludgeAroundIOS8CollectionViewCellSizingIssues:(UICollectionViewCell *)cell {
// transfer constraints involving descendants on cell to contentView
UIView *contentView = cell.contentView;
NSArray *cellConstraints = [cell constraints];
for (NSLayoutConstraint *cellConstraint in cellConstraints) {
if (cellConstraint.firstItem == cell && cellConstraint.secondItem) {
NSLayoutConstraint *parallelConstraint = [NSLayoutConstraint constraintWithItem:contentView attribute:cellConstraint.firstAttribute relatedBy:cellConstraint.relation toItem:cellConstraint.secondItem attribute:cellConstraint.secondAttribute multiplier:cellConstraint.multiplier constant:cellConstraint.constant];
parallelConstraint.priority = cellConstraint.priority;
[cell removeConstraint:cellConstraint];
[contentView addConstraint:parallelConstraint];
} else if (cellConstraint.secondItem == cell && cellConstraint.firstItem) {
NSLayoutConstraint *parallelConstraint = [NSLayoutConstraint constraintWithItem:cellConstraint.firstItem attribute:cellConstraint.firstAttribute relatedBy:cellConstraint.relation toItem:contentView attribute:cellConstraint.secondAttribute multiplier:cellConstraint.multiplier constant:cellConstraint.constant];
parallelConstraint.priority = cellConstraint.priority;
[cell removeConstraint:cellConstraint];
[contentView addConstraint:parallelConstraint];
}
}
// restore auto-resizing mask to iOS 7 behavior
contentView.autoresizingMask = UIViewAutoresizingFlexibleWidth | UIViewAutoresizingFlexibleHeight;
[cell setNeedsUpdateConstraints];
[cell updateConstraintsIfNeeded];
}
This is a bug in xCode6 and iOS 8 SDK running on iOS7 devices :)
It almost waisted my day. Finally it worked with the below code in the UICollectionViewCell sub class. I hope this will be fixed with the next version
- (void)setBounds:(CGRect)bounds {
[super setBounds:bounds];
self.contentView.frame = bounds;
}
I had the same issue for UITableViewCells and iOS 7 (ios8 works perfectly), but "Triet Luong" solution worked for me:
return [sampleCell.containerView systemLayoutSizeFittingSize:UILayoutFittingCompressedSize];
This is not a bug, I have been grappling with this issue now for some time and have tried different things, I am giving below the steps that's worked for me:
1) use contentView [sampleCell.contentView systemLayoutSizeFittingSize:UILayoutFittingCompressedSize];
2) you can create your own contentView and have the subViews added to the contentView, don't forget to pin the top, bottom and left and right of the contentView if you are using a custom contentView to the superView, if you don't do this then height will be 0, here also depending upon your requirements you can for. e.g not pin the bottom of the contentView to the superView so that the height of the view can vary, but pinning is important and pinning which one depends on your requirements.
3) set the constraints properly in interface builder depending upon your requirements, there are certain constraints that cannot be added in interface builder, but then you can add them in viewDidLoad of the viewController.
So my 2 cents input is that constraints have to be set properly in the interface builder for systemLayoutSizeFittingSize:UILayoutFittingCompressedSize to return correct dimensions, this is the solution guys.
maybe you have some wrong constrain, you should specify both virtical top space and bottom space between your UIView and contentView, i also had this issue before, that is because i just specified the virtical top space, and didn't specfied the virtical bottom space to contentView
It was a bug in iOS 8 beta versions. Finally it is fixed with for iOS 8 GB (Build 12A365). So for me now it works with the same code I wrote for iOS 7. (see the question)
There were auto-resizable table view cells introduced in iOS8 (WWDC Session 226 What's new in table and collection views).
In my project I'm trying to implement old fixed rows height behavior. Also, the most important thing for me is to inset default cell.contentView frame with margins on the left and right side.
So, I change the cell.contentView.frame property and immediately after that the -[cell setNeedsLayout] method is being called and and it leads to cell get stuck in an infinite layoutSubviews loop.
Steps to reproduce:
Create new single view project and replace default view controller with the table view controller
Disable table view automatic height calculation
-(void)viewDidLoad {
[super viewDidLoad];
self.tableView.estimatedRowHeight = 0;
self.tableView.rowHeight = 44;
}
3. Drop a custom cell in the table view in storyboard,
Add any subview to the custom cell:,
Subclass the cell and change contentView.frame in layoutSubviews,
Build and run.
Result:
Simulator ends up in a black screen stuck in a infinite layout subviews loop.
Expected Result:
Simulator displaying a table view with a cell's contentView having a custom frame.
Comment:
While debugging a little bit, I found that the infinite loop can be avoided if the cell does not have any custom subviews dropped on it. So it seems the bug will appear after the following conditions are met:
self.tableView.estimatedRowHeight = 0; self.tableView.rowHeight = 44;
cell.contentView.frame = CGRectMake(...)
cell have custom subviews dropped on it in xib or storyboard
Apple does not have the issue in the "Known issues" list for iOS8, so I'm wondering is it actually a bug in iOS8 or does anybody know how to resolve the issue?
This is not a bug: setNeedsLayout will be called any time you change view's frame.
My guess is that changing cell.contentView.frame also changes cell.bounds in iOS 8, triggering relayout. This behavior may be different between iOS versions; anyway, those are standard views, so we shouldn't change them in unsupported ways.
Rather than operating on cell.contentView, how about adding a custom view with insets to it? Or simply creating a height constraint?
In ViewDidLoad please use the below line and there is no need to give the row height
-(void)viewDidLoad {
[super viewDidLoad];
self.tableView.estimatedRowHeight = 44.0f;
self.tableView.rowHeight = UITableViewAutomaticDimension;
}