Animar Views por Constraint e referenciá-las por código

Criar animações com constraints pode se tornar muito mais fácil quando conseguimos pegá-las por código.

Felipe Kaça Petersen
4 min readApr 14, 2020

Hoje em dia, ter animações em nossos aplicativos é algo fundamental. As vezes basta um detalhe, um simples efeito em algum objeto, para dar um efeito completamente diferente na experiência do app. Na apresentação da Apple Design Awards na WWDC 2019 foram citadas inúmeras vezes o quanto o detalhe consegue fazer a diferença na imersão do usuário.

É exatamente neste ponto que entram as animações, pode ser apenas um detalhe, um ponto que muitos usuários podem deixar passar batido, ou então algo maior, que chame mais a atenção. Quando paramos para analisar alguns apps, vemos que eles estão cheios de efeitos, desde os mais chamativos até os mais pontuais.

Usando o AutoLayout, fica muito fácil de animar um objeto da nossa tela, o maior desafio então, é deixar essa animação confortável para o usuário.

Animação Básica com Constraints

O nosso primeiro passo é criar um outlet da constraint que desejamos animar. Constraints podem ser “puxadas” para o código assim como qualquer outro objeto, possibilitando fazer alterações nela.

Agora, com a referência da constraint, podemos alterar seu valor para o novo desejado, fazendo a view se mover.

Vamos analisar o que está sendo feito em cada linha:

  1. Primeiro, mudamos o valor da constante do nosso outlet da constraint. Neste ponto, não estamos fazendo alteração alguma, pois ainda a tela não foi atualizada.
  2. Nessa linha, construimos o bloco de animação, que pode ser como for melhor para a experiência que deseja alcançar. Não vamos tratar sobre a função “animate” neste artigo. Para saber mais sobre UIView.animate(), leia esse artigo.
  3. Quando chamamos o layoutIfNeeded(), a view busca por mudanças pendentes no layout, incluindo nossa alteração na constraint. Para saber mais, podemos ler sobre na documentação.

O nosso resultado será este:

Referenciando a constraint sem usar IBOutlet

Quando estamos trabalhando com um número maior de views em nosso projeto, podemos ter o problema de ter diversas referências de constraints em nosso código, o que pode deixá-lo mais confuso e menos flexível. Uma boa forma de fazer isso seria pegar a constraint diretamente da view que estamos trabalhando.

Problema 1

Nosso primeiro problema é que as constraints não estão ligadas a sua view, e sim a view que a pertence, ou seja, a “view pai”. Então, para conseguir referenciar a constraint, não buscamos na view em si, e sim na sua superview.

Para contornar esse problema, podemos fazer uma extension da nossa UIView e criar uma função que retorne todas as constraints.

Problema 2

Agora que conseguimos pegar todas as constraints de nossa view, temos mais um problema, que é saber qual constraint nós queremos, já que podemos ter várias atreladas ao mesmo elemento. Por ser do tipo NSLayoutConstraint, a leitura e identificação pode ficar bem confusa. No nosso exemplo, quando printamos as suas constraints, temos algo assim:

Podemos contornar esse problema de forma simples, apenas atribuindo um identifier para cada constraint, assim conseguimos diferenciá-las com o nosso identificador. Para criar esse identificador, selecionamos a constraint no nosso storyboard e no Attributes Inspector e inserimos o nome para o identifier.

Assim, podemos fazer um filtro das constraints que temos para a view e buscar pelo identificador correspondente que desejamos, que no nosso caso se chama “top”. Ele retorna o primeiro (“first”) que corresponder aquele identificador. Podemos fazer isso como no código abaixo:

Importante notar que, por conta de cada view possuir suas próprias constraints, não existe problema algum nomear com o mesmo identificador para views diferentes. Sendo assim, para todas as views, o identificador da constraint para o top pode se chamar “top”, por exemplo. Isso facilita quando trabalhamos com diversas views e diversas animações para cada, de modo que não nos preocupamos com o nome de seu identificador, desde que sigamos um padrão.

Você pode ver o projeto inteiro neste link.

--

--

Felipe Kaça Petersen

Desenvolvedor por 4 anos, sendo 2 dedicados a Flutter e 2 dedicados a iOS, com passagens também como UI/UX em projetos pontuais.