With the release of iOS8 I have designed my table view with cells taking advantage of self sizing cells. But I need my tables to work in iOS7 as well. How do I do that? Is there a way to check whether self sizing cells is supported or not in runtime, or can I implement some table delegate methods in my controller which will not be called in iOS7?
If I try my table with self sizing cells in iOS7 I get errors on the console like this:
Unable to simultaneously satisfy constraints.
Probably at least one of the constraints in the following list is one you don't want. Try this: (1) look at each constraint and try to figure out which you don't expect; (2) find the code that added the unwanted constraint or constraints and fix it. (Note: If you're seeing NSAutoresizingMaskLayoutConstraints that you don't understand, refer to the documentation for the UIView property translatesAutoresizingMaskIntoConstraints)
(
"<NSLayoutConstraint:0x7fc912d1d5a0 V:|-(>=11)-[UILabel:0x7fc912d13900] (Names: '|':UITableViewCellContentView:0x7fc912d13400 )>",
"<NSLayoutConstraint:0x7fc912d1d6b0 V:[UILabel:0x7fc912d13900]-(11)-| (Names: '|':UITableViewCellContentView:0x7fc912d13400 )>",
"<NSAutoresizingMaskLayoutConstraint:0x7fc912d24d80 h=--& v=--& V:[UITableViewCellContentView:0x7fc912d13400(0.5)]>"
)
This is the solution I have found thus far, but it requires checking for specific version number rather than capability. You only set UITableViewAutomaticDimension if you have iOS 8 or higher as version:
override func viewDidLoad() {
if NSFoundationVersionNumber > NSFoundationVersionNumber_iOS_7_1 {
self.tableView.estimatedRowHeight = 80
self.tableView.rowHeight = UITableViewAutomaticDimension
}
}
For iOS 7 you need to calculate a height for each cell. But if you are on iOS 8 you can return UITableViewAutomaticDimension as the height:
override func tableView(tableView: UITableView, heightForRowAtIndexPath indexPath: NSIndexPath) -> CGFloat {
if NSFoundationVersionNumber > NSFoundationVersionNumber_iOS_7_1 {
return UITableViewAutomaticDimension
}
return 50 // Or whatever calculated value you need for cell height
}
For iOS versions older than 8.0, you can always write the usual heightForRowAtIndexPath method where you create a cell, run an auto layout pass on it and then return the actual height.
Related
I am having issues getting rid of a pesky NSAutoresizingMaskLayoutConstraint that is breaking the auto-layout width constraints of some UITextView.
I have a UITableviewCell that contains a text view, and the text view's height is dynamically set based on the content of the text view's text using
self.table.sectionHeaderHeight = UITableView.automaticDimension;
self.table.estimatedSectionHeaderHeight = 200;
This works pretty well when auto-layout is used (I am setting my constraints via the interface and not code). However, I noticed that the widths of the text views are conflicting with NSAutoresizingMaskLayoutConstraint - and the end result is the width constraint on my text view is being removed.
[LayoutConstraints] Unable to simultaneously satisfy constraints.
Probably at least one of the constraints in the following list is one you don't want.
Try this:
(1) look at each constraint and try to figure out which you don't expect;
(2) find the code that added the unwanted constraint or constraints and fix it.
(Note: If you're seeing NSAutoresizingMaskLayoutConstraints that you don't understand, refer to the documentation for the UIView property translatesAutoresizingMaskIntoConstraints)
(
"<NSAutoresizingMaskLayoutConstraint:0x6000012ff070 h=--& v=--& UITextView:0x7fde2f09e600'At teenfvfed'.width == 89.5 (active)>",
"<NSLayoutConstraint:0x600001292210 UITextView:0x7fde2f09e600'At teenfvfed'.width == 293 (active)>"
)
Will attempt to recover by breaking constraint
<NSLayoutConstraint:0x600001292210 UITextView:0x7fde2f09e600'At teenfvfed'.width == 293 (active)>
The common answer I see online is to add translatesAutoresizingMaskIntoConstraints = false on the text view, but this doesn't have any effect and NSAutoresizingMaskLayoutConstraint remains. Any help would be greatly appreciated to remove this!
Try this:
override func tableView(_ tableView: UITableView, willDisplay cell: UITableViewCell, forRowAt indexPath: IndexPath) {
cell.text.translatesAutoresizingMaskIntoConstraints = false
cell.setNeedsLayout()
cell.layoutIfNeeded()
}
I have a UITableViewCell with collectionView inside it. constraint are pretty simple leading 0 , trailing 0 , top 10 and bottom 10 and height constraint of UICollection view is 160 . Connected an IBOutlet to height constraint. In cell for row I am updating the heigth constraint.
But getting error in debug
Code of cell for row is
func videoCell(for tableView:UITableView ,with indexPath:IndexPath , videos:[VideoCollectionViewCellConfigure] ) -> VideoTableViewCell {
let cell = tableView.dequeueReusableCell(withIdentifier: "VideoTableViewCell", for: indexPath) as! VideoTableViewCell
cell.videoConfigurators = videos
cell.collectionCellClickedBlock = self.videoCollectionCellClicked(_:_:)
if videos.count > 0 {
let video = videos[0]
cell.videoCollectionViewHeightConstraint.constant = video.height
}
cell.videoCollectionView.reloadData()
return cell
}
2018-04-16 12:42:10.815998+0530 CineBee[5280:74417] [LayoutConstraints]
Unable to simultaneously satisfy constraints.
Probably at least one of the constraints in the following list is one you don't want.
Try this:
(1) look at each constraint and try to figure out which you don't expect;
(2) find the code that added the unwanted constraint or
constraints and fix it.
(
"<NSLayoutConstraint:0x6000006878a0 UICollectionView:0x7f86109c4c00.height
== 180 (active)>",
"<NSLayoutConstraint:0x604000885870 V:[UICollectionView:0x7f86109c4c00]-(10)-| (active, names: '|':UITableViewCellContentView:0x7f8615803ca0 )>",
"<NSLayoutConstraint:0x604000888de0 V:|-(10)-
[UICollectionView:0x7f86109c4c00] (active, names: '|':UITableViewCellContentView:0x7f8615803ca0 )>",
"<NSLayoutConstraint:0x60400088dde0 'UIView-Encapsulated-Layout-Height'
UITableViewCellContentView:0x7f8615803ca0.height == 180.5 (active)>"
)
Will attempt to recover by breaking constraint
<NSLayoutConstraint:0x6000006878a0
UICollectionView:0x7f86109c4c00.height == 180 (active)>
Try this
override func tableView(_ tableView: UITableView, heightForRowAt indexPath: IndexPath) -> CGFloat {
var defaultHeight = /*your default height*/
if videos.count > 0 {
let video = videos[0]
return video.height + 10 + 10 // video height + top padding + bottom padding
}
return defaultHeight
}
Also remove the collectionView height constraint from the Interface builder. Now you don't have to set constraint in the cellForItemAtIndexPath.
According to your error report, it seems like the case I was attempting to address in this SO question. If the conflicting constraints contain UIView-Encapsulated-Layout-Height it means the conflict arises during calculating dynamic height based on autolayout. Just lower one of the vertical constraints priority to 999 - if the code works, it's ok and you are good to go.
So, my table view displays images. Every cell is basically an image filling out the cells entire contentView. As the images come with different aspect ratios, I need my cells to be adjusting their height depending on the table views width and the aspect ratio of the image. I've followed this Ray Wenderlich tutorial but now get a constraint conflict. The image is resized by altering the imageViews height constraint e.g. myImageViewHeight.constant = tableView.frame.width / aspectRatio
2016-06-16 13:56:25.823 MyApp[92709:5649464] Unable to simultaneously satisfy constraints.
Probably at least one of the constraints in the following list is one you don't want.
Try this:
(1) look at each constraint and try to figure out which you don't expect;
(2) find the code that added the unwanted constraint or constraints and fix it.
(
"<NSLayoutConstraint:0x7fbcdaf5c190 V:[UIImageView:0x7fbcdaf5c300(303)]>",
"<NSLayoutConstraint:0x7fbcdaf5b460 V:|-(0)-[UIImageView:0x7fbcdaf5c300] (Names: '|':UITableViewCellContentView:0x7fbcdaf52230 )>",
"<NSLayoutConstraint:0x7fbcdaf5b4b0 V:[UIImageView:0x7fbcdaf5c300]-(0)-| (Names: '|':UITableViewCellContentView:0x7fbcdaf52230 )>",
"<NSLayoutConstraint:0x7fbcdaf5e550 'UIView-Encapsulated-Layout-Height' V:[UITableViewCellContentView:0x7fbcdaf52230(100)]>"
)
Will attempt to recover by breaking constraint
<NSLayoutConstraint:0x7fbcdaf5c190 V:[UIImageView:0x7fbcdaf5c300(303)]>
The image view has the following constraints and has the cells contentView as superview.
In the table view controller class, I'm using
self.tableView.estimatedRowHeight = 80
self.tableView.rowHeight = UITableViewAutomaticDimension
I've also tried this - same result.
func tableView(tableView: UITableView, heightForRowAtIndexPath indexPath: NSIndexPath) -> CGFloat {
return UITableViewAutomaticDimension
}
func tableView(tableView: UITableView, estimatedHeightForRowAtIndexPath indexPath: NSIndexPath) -> CGFloat {
return UITableViewAutomaticDimension
}
I'm guessing that I have to get rid of the 'UIView-Encapsulated-Layout-Height' V:[UITableViewCellContentView:0x7fbcdaf52230(100)]>" but how? Also, does anybody know some kind of documentation/tutorials on how to properly create table views with dynamic content that not only cover having a bunch of labels inside the cell? My code works just fine if the image view is replaced by a label...
You implementation is correct don't change anything in your code or any of your constraints.Removing the warning is easy just select the height constraint and lower its priority from 1000 to 999 it will fix your warning.If it still comes, let me know.
It is an old question but I put this just for the record.
The problem here is the estimated hight, 80, that is lower then the computed hight, 100.
Changing the estimated hight to >=100 should fix this warning.
I have a complex view hierarchy, built in Interface Builder, with nested UIStackViews. I get "unsatisfiable constraints" notices every time I hide some of my inner stackviews. I've tracked it down to this:
(
"<NSLayoutConstraint:0x1396632d0 'UISV-canvas-connection' UIStackView:0x1392c5020.top == UILabel:0x13960cd30'Also available on iBooks'.top>",
"<NSLayoutConstraint:0x139663470 'UISV-canvas-connection' V:[UIButton:0x139554f80]-(0)-| (Names: '|':UIStackView:0x1392c5020 )>",
"<NSLayoutConstraint:0x139552350 'UISV-hiding' V:[UIStackView:0x1392c5020(0)]>",
"<NSLayoutConstraint:0x139663890 'UISV-spacing' V:[UILabel:0x13960cd30'Also available on iBooks']-(8)-[UIButton:0x139554f80]>"
)
Specifically, the UISV-spacing constraint: when hiding a UIStackView its high constraint gets a 0 constant, but that seems to clash with the inner stackview's spacing constraint: it requires 8 points between my Label and Button, which is irreconcilable with the hiding constraint and so the constraints crash.
Is there a way around this? I've tried recursively hiding all the inner StackViews of the hidden stack view, but that results in strange animations where content floats up out of the screen, and causes severe FPS drops to boot, while still not fixing the problem.
This is a known problem with hiding nested stack views.
There are essentially 3 solutions to this problem:
Change the spacing to 0, but then you'll need to remember the previous spacing value.
Call innerStackView.removeFromSuperview(), but then you'll need to remember where to insert the stack view.
Wrap the stack view in a UIView with at least one 999 constraint. E.g. top#1000, leading#1000, trailing#1000, bottom#999.
The 3rd option is the best in my opinion. For more information about this problem, why it happens, the different solutions, and how to implement solution 3, see my answer to a similar question.
So, you have this:
And the problem is, when you first collapse the inner stack, you get auto layout errors:
2017-07-02 15:40:02.377297-0500 nestedStackViews[17331:1727436] [LayoutConstraints] Unable to simultaneously satisfy constraints.
Probably at least one of the constraints in the following list is one you don't want.
Try this:
(1) look at each constraint and try to figure out which you don't expect;
(2) find the code that added the unwanted constraint or constraints and fix it.
(
"<NSLayoutConstraint:0x62800008ce90 'UISV-canvas-connection' UIStackView:0x7fa57a70fce0.top == UILabel:0x7fa57a70ffb0'Top Label of Inner Stack'.top (active)>",
"<NSLayoutConstraint:0x62800008cf30 'UISV-canvas-connection' V:[UILabel:0x7fa57d30def0'Bottom Label of Inner Sta...']-(0)-| (active, names: '|':UIStackView:0x7fa57a70fce0 )>",
"<NSLayoutConstraint:0x62000008bc70 'UISV-hiding' UIStackView:0x7fa57a70fce0.height == 0 (active)>",
"<NSLayoutConstraint:0x62800008cf80 'UISV-spacing' V:[UILabel:0x7fa57a70ffb0'Top Label of Inner Stack']-(8)-[UILabel:0x7fa57d30def0'Bottom Label of Inner Sta...'] (active)>"
)
Will attempt to recover by breaking constraint
<NSLayoutConstraint:0x62800008cf80 'UISV-spacing' V:[UILabel:0x7fa57a70ffb0'Top Label of Inner Stack']-(8)-[UILabel:0x7fa57d30def0'Bottom Label of Inner Sta...'] (active)>
Make a symbolic breakpoint at UIViewAlertForUnsatisfiableConstraints to catch this in the debugger.
The methods in the UIConstraintBasedLayoutDebugging category on UIView listed in <UIKit/UIView.h> may also be helpful.
The problem, as you noted, is that the outer stack view applies a height = 0 constraint to the inner stack view. This conflicts with the 8 point padding constraint applied by the inner stack view between its own subviews. Both constraints cannot be satisfied simultaneously.
The outer stack view uses this height = 0 constraint, I believe, because it looks better when animated than just letting the inner view be hidden without shrinking first.
There's a simple fix for this: wrap the inner stack view in a plain UIView, and hide that wrapper. I'll demonstrate.
Here's the scene outline for the broken version above:
To fix the problem, select the inner stack view. From the menu bar, choose Editor > Embed In > View:
Interface Builder created a width constraint on the wrapper view when I did this, so delete that width constraint:
Next, create constraints between all four edges of the wrapper and the inner stack view:
At this point, the layout is actually correct at runtime, but Interface Builder draws it incorrectly. You can fix it by setting the vertical hugging priorities of the inner stack's children higher. I set them to 800:
We haven't actually fixed the unsatisfiable constrain problem at this point. To do so, find the bottom constraint that you just created and set its priority to less than required. Let's change it to 800:
Finally, you presumably had an outlet in your view controller connected to the inner stack view, because you were changing its hidden property. Change that outlet to connect to the wrapper view instead of the inner stack view. If your outlet's type is UIStackView, you'll need to change it to UIView. Mine was already of type UIView, so I just reconnected it in the storyboard:
Now, when you toggle the wrapper view's hidden property, the stack view will appear to collapse, with no unsatisfiable constraint warnings. It looks virtually identical, so I won't bother posting another GIF of the app running.
You can find my test project in this github repository.
I hit a similar problem with UISV-hiding. For me, the solution was to reduce the priorities of my own constraints from Required (1000) to something less than that. When UISV-hiding constrains are added, they take priority and the constraints no longer clash.
Ideally we could just set the priority of the UISV-spacing constraint to a lower value, but there doesn't appear to be any way to do that. :)
I am having success setting the spacing property of the nested stack views to 0 before hiding, and restoring to the proper value after making it visible again.
I think doing this recursively on nested stack views would work. You could store the original value of the spacing property in a dictionary and restore it later.
My project only has a single level of nesting, so I am unsure if this would result in FPS problems. As long as you don't animate the changes in spacing, I don't think it would create too much of a hit.
Another approach
Try to avoid nested UIStackViews. I love them and build almost everything with them. But as I recognized that they secretly add constraints I try to only use them at the highest level and non-nested where possible. This way I can specify the 2nd highest priority .defaultHighto the spacing constraint which resolves my warnings.
This priority is just enough to prevent most layout issues.
Of course you need to specify some more constraints but this way you have full control of them and make your view layout explicit.
Here's implementation of Senseful's suggestion #3 written as Swift 3 class using SnapKit constraints. I also tried overriding the properties, but never got it working without warnings, so I'll stick with wrapping UIStackView:
class NestableStackView: UIView {
private var actualStackView = UIStackView()
override init(frame: CGRect) {
super.init(frame: frame);
addSubview(actualStackView);
actualStackView.snp.makeConstraints { (make) in
// Lower edges priority to allow hiding when spacing > 0
make.edges.equalToSuperview().priority(999);
}
}
convenience init() {
self.init(frame: CGRect.zero);
}
required init?(coder aDecoder: NSCoder) {
fatalError("init(coder:) has not been implemented")
}
func addArrangedSubview(_ view: UIView) {
actualStackView.addArrangedSubview(view);
}
func removeArrangedSubview(_ view: UIView) {
actualStackView.removeArrangedSubview(view);
}
var axis: UILayoutConstraintAxis {
get {
return actualStackView.axis;
}
set {
actualStackView.axis = newValue;
}
}
open var distribution: UIStackViewDistribution {
get {
return actualStackView.distribution;
}
set {
actualStackView.distribution = newValue;
}
}
var alignment: UIStackViewAlignment {
get {
return actualStackView.alignment;
}
set {
actualStackView.alignment = newValue;
}
}
var spacing: CGFloat {
get {
return actualStackView.spacing;
}
set {
actualStackView.spacing = newValue;
}
}
}
In my case I was adding width and height constraint to a navigation bar button, as per the advice above I only added lower priority to the constraints.
open func customizeNavigationBarBackButton() {
let _selector = #selector(UIViewController._backButtonPressed(_:))
let backButtonView = UIButton(type: .custom)
backButtonView.setImage(UIImage(named: "icon_back"), for: .normal)
backButtonView.imageEdgeInsets = UIEdgeInsets.init(top: 0, left: -30, bottom: 0, right: 0)
backButtonView.snp.makeConstraints { $0.width.height.equalTo(44).priority(900) }
backButtonView.addTarget(self, action: _selector, for: .touchUpInside)
let backButton = UIBarButtonItem(customView: backButtonView)
self.navigationItem.leftBarButtonItem = backButton
}
I am trying to use AutoLayout to configure the subviews in my table view cells and in the ideal case would like the table view cell to be just as high as necessary to contain all the subviews. However, that does not seems to be possible, since the height for a cell is determined before the cell is actually created.
So, for now, I just looked at the constraints I set up and calculated the total height needed to contain everything and set that in the storyboard as the row height for this specific TableViewCell prototype cell and I also return this height in the tableView:heightForRowAtIndexPath: method.
Now, my table view cell looks like this (screenshot from storyboard):
There are two constraints which don't have a size shown, they both have the size 10 (the button-top-container-view and the distance between the slider and the label in the middle).
Going from top-to-bottom the following distance occur:
10 (distance)
50 (height of button)
20 (distance)
20 (height of label)
10 (distance)
30 (height of slider)
20 (distance)
leading to a total height of 160.
That's exactly what I have set in the inspector of this cell:
but as you can see from the first screenshot, Interface builder complains that the constraints are conflicting (that's why they are displayed in red). IB is satisfied if I set the height to 161, but that is wrong.
Also, if I do, I get exceptions at runtime due to conflicting constraints:
Unable to simultaneously satisfy constraints.
Probably at least one of the constraints in the following list is one you don't want. Try this: (1) look at each constraint and try to figure out which you don't expect; (2) find the code that added the unwanted constraint or constraints and fix it. (Note: If you're seeing NSAutoresizingMaskLayoutConstraints that you don't understand, refer to the documentation for the UIView property translatesAutoresizingMaskIntoConstraints)
(
"<NSLayoutConstraint:0x8d80240 V:[UISlider:0x8d81190(30)]>",
"<NSLayoutConstraint:0x8d833e0 V:[UILabel:0x8d83300(20)]>",
"<NSLayoutConstraint:0x8d83750 V:[UIButton:0x8d83600(50)]>",
"<NSLayoutConstraint:0x8d85050 V:|-(10)-[UIButton:0x8d83600] (Names: '|':UITableViewCellContentView:0x8d80ef0 )>",
"<NSLayoutConstraint:0x8d851d0 V:[UILabel:0x8d83300]-(10)-[UISlider:0x8d81190]>",
"<NSLayoutConstraint:0x8d85200 V:[UISlider:0x8d81190]-(20)-| (Names: '|':UITableViewCellContentView:0x8d80ef0 )>",
"<NSLayoutConstraint:0x8d85320 V:[UIButton:0x8d83600]-(20)-[UILabel:0x8d83300]>",
"<NSAutoresizingMaskLayoutConstraint:0x8d8b7a0 h=--& v=--& V:[UITableViewCellContentView:0x8d80ef0(161)]>"
)
the last one is the only one I did not explicitly set, but it seems to be generated from the row-height setting in the storyboard, since my tableView:heightForRowAtIndexPath: method returns 160:
-(CGFloat)tableView:(UITableView *)tableView heightForRowAtIndexPath:(NSIndexPath *)indexPath
{
if (indexPath.row == self.fetchedItemSetsController.fetchedObjects.count - 1)
{
return 160;
}
return 44;
}
(at the moment I always want the last cell to be the large and special one)
So, okay, IB complains when I set the row height to 160, but when I set it to 161 the runtime complains. So I tried ignoring IB and set the row height to 160 in the storyboard as well (as seen in the second screenshot). In that case, I get the same error message with a tiny difference:
"<NSLayoutConstraint:0x17809ce80 V:[UISlider:0x125613660(30)]>",
"<NSLayoutConstraint:0x1782814f0 V:[UILabel:0x125615100(20)]>",
"<NSLayoutConstraint:0x178281a90 V:[UIButton:0x125615b50(50)]>",
"<NSLayoutConstraint:0x178281b80 V:|-(10)-[UIButton:0x125615240] (Names: '|':UITableViewCellContentView:0x178161980 )>",
"<NSLayoutConstraint:0x178281c20 UIButton:0x1256157b0.height == UIButton:0x125615240.height>",
"<NSLayoutConstraint:0x178281d10 UIButton:0x1256157b0.height == UIButton:0x125615980.height>",
"<NSLayoutConstraint:0x178281e00 V:[UILabel:0x125615100]-(10)-[UISlider:0x125613660]>",
"<NSLayoutConstraint:0x178281e50 V:[UISlider:0x125613660]-(20)-| (Names: '|':UITableViewCellContentView:0x178161980 )>",
"<NSLayoutConstraint:0x178281f40 UIButton:0x125615980.height == UIButton:0x125615b50.height>",
"<NSLayoutConstraint:0x178282030 V:[UIButton:0x125615240]-(20)-[UILabel:0x125615100]>",
"<NSAutoresizingMaskLayoutConstraint:0x178283340 h=--& v=--& V:[UITableViewCellContentView:0x178161980(159.5)]>"
The constraint for the height of the table view cell is now 159.5 instead of 160. I also encountered it as 160.5 before, with the same storyboard setting, but I am not sure where that came from.
So, first I thought it was just a display bug in IB, but now it actually seems to be creating the wrong constraint. It creates a constraint with 160.5 (or 159.5) instead of the 160 I specified. Why is that? What can I do about it?
Btw: The cells seems to be displayed correctly, but then again I doubt I would be able to see a 0.5 point difference. Mainly, I would like to get rid of the exceptions, since they make the debugging much harder, but I would also like to know what is going on here.
UPDATE:
The 159.5 is not JUST due to the storyboard setting I just noticed, it is a strange combination of the storyboard setting and the return value of the tableView:heightForRowAtIndexPath:.
Here are a few examples of the height of the generated autoresizingmasklayoutconstraint depending on the storyboard height (sb) setting and the return value of the tableView:heightForRowAtIndexPath: method (method). In all cases, the constraints of the subview should lead to a height of 160 and are not changed.
160 (sb) & 160 (method): 159.5 (constraint)
161 (sb) & 160 (method): 159.5 (constraint)
160 (sb) & 161 (method): 160.5 (constraint)
162 (sb) & 161 (method): 162 (constraint)
161 (sb) & 162 (method): 161 (constraint)
162 (sb) & 162 (method): 162 (constraint)
So I thought, okay, for (6.) they all agree, I will just make the label's height 22, so the total height according to the subviews will be 162 as well. Result:
6a. 162 (sb) & 162 (method), 162 (total height of subviews): 161.5 (constraint)
WHAT?!
Any ideas what's happening here?
Update 2
I provided an example project that reproduces the issue on Github.
Separator is messing with the height of the contentView, either it should be disabled (and replaced with custom one if required) so that the contentView height matches the height of the cell or the constraints should be changed to more flexible considering that the contentView height may mismatch the height of the cell. Doing both would be even better.
Now that you've uploaded the example to github, I was able to see that the constraints were in fact over-determined. There was too much "this is equal to that", esp. in the area of vertical spacings/heights. I simplified the constraints, and was able to change to your code to this:
-(CGFloat)tableView:(UITableView *)tableView
heightForRowAtIndexPath:(NSIndexPath *)indexPath
{
if (indexPath.row == 0)
{
return 44;
} // else
UITableViewCell* cell =
[tableView dequeueReusableCellWithIdentifier:#"LargeCell"];
CGSize sz =
[cell.contentView systemLayoutSizeFittingSize:UILayoutFittingExpandedSize];
return sz.height;
}
If I'm not mistaken, that's exactly the sort of thing you are after, i.e. to let the constraints themselves dictate the height of the cell.