Is the "installed" property only for enabling/disabling constraints for different size classes and not for runtime changes?
I want to have multiple sets of constraints that I enable/disable based on some condition on a view inside an UITableViewCell.
But if I design them all in IB and uncheck installed for some of them and then try to activate/deactivate them during runtime, nothing happens. I am storing strong references and I have tried numerous setNeedsDisplay/setNeedsUpdateConstraints on the different views.
The only way to make it work is to have all of them installed and the extra ones be with priority of 999, to avoid errors. Then I can activate/deactivate them during runtime with no problems.
You should use the isActive property. Remember to do this on the main thread by using DispatchQueue.main.async{ ... }
You can activate your constraints if you have an IBOutlet for each one of them.
You need to be carefull though and disable those that will conflict before activate your constraint otherwise it will fail, that most likely is your issue.
Related
I have a view that I have made 2 sets of constraints for it. In the code, sometimes I make one set active and the other inactive. During runtime everything works fine, no errors or warnings constraint related. But when I go to IB, I have quite a few errors because of conflicting constraints. How can I deal with IB, is there a way to set some setting in IB, so it knows that not all those constraints are meant to be used at the same time?
select your constraint in the IB and then set the priorties according to your need...enter image description here
change the priorty to 999 or select a value from the drop down.
There is autosizing option available until you give any constraints to UI Component.
So can I use both for my ViewController?
You could, but you shouldn't
You can use constraints on some views, and autosizing on others, but be careful not to mix them on the same view, as that will cause issues (the autosizing information will be lost).
iOS takes care of autosizing views by creating constraints that convey the information of the autosizing to the constraints engine. This behaviour can be enabled or disabled by the aptly named translatesAutoresizingMaskIntoConstraints property.
You could try to add constraints to a view and still have it autoresize with the old behaviour by setting this value to true, but I suggest you use constraints for every view, as it can do everything the autosizing can, and much more.
Yes, you can (use a mixture of constraints and autoresizing on subviews within a single view) within Xcode 8. See:
02:38 https://developer.apple.com/videos/play/wwdc2016/236/
With Xcode 8, the translatesAutoresizingMaskIntoConstraints property for each view is automatically maintained by Interface Builder:
By default, when a child view is first added, the value of the property is true.
When the first constraint is added to the child view, the value is automatically set to false and the Size Inspector pane changes to the Constraints view.
When the last constraint is removed from the child view, the value of the property is automatically reverted to true, and the Size inspector reverts to the Autoresizing view.
If you create a view programatically, Xcode will generate constraints to satisfy autoresizing itself (translatesAutoresizingMaskIntoConstraints is set to true). However if you create a view in IB, Apple says:
If you add views in Interface Builder, the
system automatically sets this property to false.
To reflect that, any view added into IB before Xcode 8 has that autoresizing option hidded (or at least I did not see it for a while there).
But here is the thing:
Since Xcode 8, the option is visible (translatesAutoresizingMaskIntoConstraints is set to true) until you add any constraint, so the Apple's text above is not actually correct I guess.
So in a single view you cannot satisfy/use both. view(autoresizing and constraints)
In subviews you can use different for each one, but it will be a mess and I cannot imagine reasonable usage. view->subview(constraints) and subview(autoresizing)
That also means that you can use e.g. view(autoresizing)->subview(constraints)
I need to completely ignore autolayout constraints on a subview. I have tried using translatesAutoresizingMaskIntoConstraints = YES as although posts have stated. This is great and allows me to set the frame of my object. What this doesn't do is ignore the auto layout constraints completely as the views I am setting translatesAutoresizingMaskIntoConstraints = YES on are still causing debugger output "will attempt to recover by breaking constraint .....".
How do I make it so the constraints won't even be referenced but truly ignored until I want to bring them back.
Is there a simple solution?
On iOS 8 and later you can deactivate the constraint by setting the active property to false. You can create a IBOutlet list so you don't have to reference all the constraints one by one and activate and deactivate them all at once.
For backwards compatibility, you can remove them from the view and add them again later.
I'm trying try hide table view and move a button up the screen, which is different to my autolayout setup. Basically, I have a free version of my app where I hide things, then if they purchase I need to set the constraints back to those in interface builder.
I have a similar question open, but I think I'm fundamentally flawed in my approach.... (I've taken the advice of something who provided and answer, asking this separate question).
ObjC, revert to interface builder autolayout constraints, after adding / removing programmatically?
I can move things up fine, which modifies my interface builder constraints.
But, when the user clicks upgrade, I cannot then set the modify they again / constraints back.
No matter what I do, use visual format language at runtime, or use NSLayoutConstraint constraintWithItem outlets to copy and then modify my constraints it doesn't change. I've tried removing constraint outlets, copying those I stored at viewdidload and remove vfl constraints, exact copies of those which I added for my free version.
I was getting some vfl warnings, until I added priorities.
Is there somewhat I can dump out the vfl for everything and try and figure out the problem or can something suggest the why the approaches I have tried have failed?
Instead of attempting to replace and restore constraints at runtime, consider setting up all the constraints you will need in Interface Builder, with references to those which are state-dependent. Then, when state changes according to your own logic, activate the state-appropriate constraint(s) and deactivate the inappropriate ones. NSLayoutConstraint has an active property, which determines whether it is used for laying out its view.
I want to disable automatic adding Relative to margin when creating constraints in IB of Xcode 6.
It's nice that they turn this option on by default, but I have to support iOS7, so it turned out I have to manually disable this option every time after adding new constraint.
I found this setting for disabling it beforehand, but it's always on by default.
The closest I've ever come to this is hacky at best, so take this for what it is...
Creating AL constraint while not holding Option:
Creating AL constraint while holding option:
In IB if you hold Option while creating the AL constraint, it toggles whether the constraint binds to a margin or not. That's one convenient way to avoid re-editing the constraint. Further (and this is the hacky part because I can't explain it) I've noticed that in projects where I start holding option and binding AL constraints without the margin, that behavior becomes the default!
Like I said, it's hacky and I can't explain it why the default changes sometimes, but holding Option when you create constraints is the closest I've ever gotten.
This plugin will set a default value of Constrain to margins to disabled.
https://github.com/mshibanami/DefaultMarginDisabler
It is by default enabled in storyboards, I have not found how to disable it.
But in Xibs, it is unchecked when you create a constraint.
A solution may be to create a storyboard that instantiates your xibs, but you will loose every possibilities given by the segues.
So You may want to deal with it since there's no option for that (so far... ?).