6
ho questo semplice visione:Auto Layout: animano modifiche al moltiplicatore di NSLayoutConstraint
- (void)viewDidLoad
{
[super viewDidLoad];
redBox = [[UIView alloc] init];
[redBox setBackgroundColor:[UIColor redColor]];
[redBox setTranslatesAutoresizingMaskIntoConstraints:NO];
[self.view addSubview:redBox];
//H:
widthConstraint = [NSLayoutConstraint constraintWithItem:redBox
attribute:NSLayoutAttributeWidth
relatedBy:NSLayoutRelationEqual
toItem:self.view
attribute:NSLayoutAttributeWidth
multiplier:0.5
constant:0.0];
[self.view addConstraint:widthConstraint];
//More constraints...
}
mi piacerebbe per animare un aumento della larghezza di Redbox.
Ho provato questo:
widthConstraint.constant = 100;
[UIView animateWithDuration:1
animations:^{
[self.view layoutIfNeeded];
}
];
questo aumenta la larghezza della visualizzazione 100 e anima, ma devo aumentarlo di una quantità proporzionale alla larghezza della sua superview. In altre parole, mi piacerebbe impostare's multiplier a 0.8.
Ma NSLayoutConstraint’s multiplier is readonly! Questo significa che devo rimuovere, modificare e riaggiungere widthConstraint ogni volta che voglio animare una modifica al suo multiplier o c'è un modo migliore?
C'è una buona ragione che è di sola lettura; cambiarlo è costoso e richiede il ricalcolo del layout; cambiare la costante, d'altra parte, è economico. Quindi, se è possibile, ad esempio, calcolare la costante corretta e modificarla, è molto più veloce. Il readonly è lì per incoraggiare questo. –
Ricalcolare dinamicamente le modifiche al layout in fase di runtime, non è esattamente ciò che è esattamente per il layout automatico? – Eric
@Eric - consultare http://floriankugler.com/blog/2013/4/21/auto-layout-performance-on-ios - il costo delle prestazioni aumenta in modo esponenziale con il numero di requisiti. È possibile utilizzare Auto Layout per ricalcolare le modifiche del layout in fase di esecuzione (sostituendo completamente il vincolo), ma l'API viene scritta per incoraggiare l'utente ad adottare un approccio performante. –