Ответ 1
Я предполагаю, что из-за вопроса о том, что вы используете автоматическую компоновку: в автоматическом макете, если у вас есть ведущее и/или верхнее ограничение, после масштабирования с помощью CGAffineTransformMakeScale
, ограничение верхнего и верхнего пределов будет повторно применено и ваш контроль будет двигаться на вас, чтобы гарантировать, что ограничение все еще выполняется.
Вы можете отключить автоматическую компоновку (это простой ответ), или вы можете:
-
дождитесь
viewDidAppear
(поскольку применяются ограничения, определенные в IB, и элемент управления будет размещен там, где мы хотим, и его свойствоcenter
будет надежным); -
теперь, когда мы имеем
center
рассматриваемого элемента управления, заменим начальные и верхние ограничения ограничениямиNSLayoutAttributeCenterX
иNSLayoutAttributeCenterY
, используя значения для свойстваcenter
, чтобы установитьconstant
дляNSLayoutConstraint
следующим образом.
Таким образом:
// don't try to do this in `viewDidLoad`; do it in `viewDidAppear`, where the constraints
// have already been set
- (void)viewDidAppear:(BOOL)animated
{
[super viewDidAppear:animated];
[self replaceLeadingAndTopWithCenterConstraints:self.imageView];
}
// Because our gesture recognizer scales the UIView, it quite important to make
// sure that we don't have the customary top and leading constraints, but rather
// have constraints to the center of the view. Thus, this looks for leading constraint
// and if found, removes it, replacing it with a centerX constraint. Likewise if it
// finds a top constraint, it replaces it with a centerY constraint.
//
// Having done that, we can now do `CGAffineTransformMakeScale`, and it will keep the
// view centered when that happens, avoiding weird UX if we don't go through this
// process.
- (void)replaceLeadingAndTopWithCenterConstraints:(UIView *)subview
{
CGPoint center = subview.center;
NSLayoutConstraint *leadingConstraint = [self findConstraintOnItem:subview
attribute:NSLayoutAttributeLeading];
if (leadingConstraint)
{
NSLog(@"Found leading constraint");
[subview.superview removeConstraint:leadingConstraint];
[subview.superview addConstraint:[NSLayoutConstraint constraintWithItem:subview
attribute:NSLayoutAttributeCenterX
relatedBy:NSLayoutRelationEqual
toItem:subview.superview
attribute:NSLayoutAttributeTop
multiplier:1.0
constant:center.x]];
}
NSLayoutConstraint *topConstraint = [self findConstraintOnItem:subview
attribute:NSLayoutAttributeTop];
if (topConstraint)
{
NSLog(@"Found top constraint");
[subview.superview removeConstraint:topConstraint];
[subview.superview addConstraint:[NSLayoutConstraint constraintWithItem:subview
attribute:NSLayoutAttributeCenterY
relatedBy:NSLayoutRelationEqual
toItem:subview.superview
attribute:NSLayoutAttributeLeft
multiplier:1.0
constant:center.y]];
}
}
- (NSLayoutConstraint *)findConstraintOnItem:(UIView *)item attribute:(NSLayoutAttribute)attribute
{
// since we're looking for the item constraints to the superview, let's
// iterate through the superview constraints
for (NSLayoutConstraint *constraint in item.superview.constraints)
{
// I believe that the constraints to a superview generally have the
// `firstItem` equal to the subview, so we'll try that first.
if (constraint.firstItem == item && constraint.firstAttribute == attribute)
return constraint;
// While it always appears that the constraint to a superview uses the
// subview as the `firstItem`, theoretically it possible that the two
// could be flipped around, so I'll check for that, too:
if (constraint.secondItem == item && constraint.secondAttribute == attribute)
return constraint;
}
return nil;
}
Спецификации вашей реализации могут различаться в зависимости от того, как вы определили ограничения элемента управления, который хотите масштабировать (в моем случае ведущий и верхний были основаны на супервизии, что упростило), но, надеюсь, это иллюстрирует решение, чтобы устранить эти ограничения и добавить новые, основанные на центре.
Вы могли бы, если бы не захотеть итерации через поиск соответствующего ограничения, как я выше, определите IBOutlet
для верхнего и ведущего ограничений, что значительно упростит процесс. Этот образец кода был взят из проекта, где по разным причинам я не мог использовать IBOutlet
для ссылок NSLayoutConstraint
. Но использование ссылок IBOutlet
для ограничений - это, безусловно, более простой способ (если вы придерживаетесь автоматического макета).
Например, если вы перейдете в Interface Builder, вы можете выделить соответствующее ограничение и control -drag для помощника редактора, чтобы сделать ваш IBOutlet
:
Если вы это сделаете, а не итерации по всем ограничениям, теперь вы можете просто сказать, например:
if (self.imageViewVerticalConstraint)
{
[self.view removeConstraint:self.imageViewVerticalConstraint];
// create the new constraint here, like shown above
}
Честно говоря, я хочу, чтобы интерфейс Builder имел возможность определять ограничения, подобные этим, прямо из коробки (т.е. вместо ограничения "ведущего контроля слева от супервизора", ограничения "центра управления слева от супервизора" ), но я не думаю, что это можно сделать в IB, поэтому я изменяю свои ограничения программно. Но, пройдя этот процесс, я могу теперь масштабировать элемент управления и не перемещать его из-за ограничений.
Как отмечалось в 0x7fffffff, если вы примените CATransform3DMakeScale
к слою, он не будет автоматически применять ограничения, поэтому вы не увидите, как он перемещается, как если бы вы применили CGAffineTransformMakeScale
к представлению. Но если вы сделаете что-либо, чтобы повторно применить ограничения (setNeedsLayout
или любые изменения в любых объектах UIView
могут привести к повторному использованию ограничений), представление будет перемещаться по вам. Таким образом, вы можете "подкрасться" в том случае, если вы восстановите преобразование слоя обратно в личность до того, как будут повторно применены ограничения, но, вероятно, безопаснее отключить автозапуск или просто исправить ограничения.