Use UIViews com moderação, Layers com precisão.
Parte 1: Uma abordagem teórica.
O processo de desenvolvimento de aplicativos é extremamente gradual. Parece totalmente óbvio que quando mais trabalha-se com algo, mais tende-se a ter um conhecimento aprofundado sobre o devido assunto, certo?
De início, com o conhecimento ainda superficial e provavelmente envolvido em projetos de pequeno porte, há com que não se tenha um senso crítico muito apurado sobre diversas tomadas de decisões como por exemplo o fato de utilizar uma biblioteca de terceiros ou desenvolver uma solução própria, utilizar ou não armazenamento local, usar uma arquitetura A ou B, além de até mesmo quando trabalhar com UIView ou Layer.
A partir daqui, foca-se no último exemplo citado, onde iremos abordar um pouco mais detalhado e explicitar algumas diferenças de UIView’s e Layers, para que assim você possa ter o senso crítico de decisão mais apurado neste ponto que, como desenvolvedores, temos o papel de buscar diariamente.
Hora de nivelar alguns pontos para um melhor proveito do que vem a seguir. Primeiro passo, antes de diferenciar Layers e UIViews, vale a leitura isolada de ambos. As documentações, por mais que não tenham uma cara muito amigável, são normalmente onde encontramos os detalhes que precisamos(pelo menos para um ponto de partida).
Como a descrição acima diz, um objeto UIView será capaz de gerenciar o conteúdo para uma área retangular na tela. Entenda gerenciar, como não apenas exibir o que está ali, mas também interações e outros recursos. UIView é a base para diversos outros componentes, como UIButton, UILabel, UIImageView entre outros.
Seguindo o mesmo flow de leitura da documentação da UIView, agora com o CALayer, conclui-se que o mesmo, tem como papel principal, o gerenciamento do conteúdo visual fornecido pelo desenvolvedor. Começamos a perceber que este cara aparenta ser um pouco mais simples que uma UIView, não?
Talvez alguns possam discordar, mas um ponto que eu sou agradecido à Apple é o fato da mesma documentar razoavelmente (sim, neste caso, o razoável já me satisfaz) bem suas classes internas, então, para uma inspeção under the hood podemos aplicar simplesmente o comando ⌘(Command) + ⌃ (Control) + Click e saber com o que estamos lidando. Inicialmente, podemos acessar a classe UIView e CALayer e deixar as mesmas lado a lado, como segue a figura abaixo.
Analisar estas classes pode parecer um pouco confuso e abstrato inicialmente, mas vamos ao que interessa. Como o foco aqui é aprimorar um senso crítico de decisão para quando utilizar um Layer ou uma UIView, um bom ponto de partida é entender onde queremos chegar, que resultado queremos entregar ao usuário adicionando um ou outro. Ao meu ver, dois pontos chaves para esta decisão podem ser vistos na imagem acima.
O primeiro ponto é que a UIView claramente possui um objeto CALayer. Ou seja, se vamos utilizar uma UIView, teoricamente teríamos a necessidade de utilizar recursos onde utilizando apenas um Layer não conseguiríamos entregar a mesma experiência ao usuário. Se uma UIView contém um objeto CALayer, também é fácil concluir que estamos trazendo um pacote de métodos mais “pesado” do que apenas utilizando o CALayer (A + B > B).
Ok, então quer dizer que se eu possuir um objeto UIView, consequentemente estou trazendo toda bagagem de um CALayer, mas o que realmente faz com que eu queria utilizar uma UIView ou um apenas um CALayer?
Há uma gatilho simples, que você pode perceber através das instâncias de uma UIView e a primeira delas é o UIResponder. Tome gosto por documentações, elas ajudam e muito.
Lendo apenas o início da documentação, percebe-se que esta classe agrega ao objeto métodos de handling, ou seja, de interação com o usuário. Deste modo é fácil começarmos a ter um senso crítico de que, caso você procure utilizar um objeto de layout apenas para um apelo visual (sem interação com usuário), pensar em utilizar uma UIView para esta situação pode começar a parecer a arte de matar uma mosca com uma bazuca. Sim, você estará trazendo com você os métodos de interação, e muitas outras features sem a menor necessidade. Detalhes que em curto prazo parecem inofensivos, mas ao longo de um projeto que comece a tomar outras dimensões, juntamente de outras práticas não muito adequadas, começa-se a perceber um efeito 🦋.
Creio que agora, uma pitada de senso crítico foi adicionado ao seu conhecimento, e assim você pode estar se perguntando algumas outras situações onde o que você aprendeu aqui possa ter impactos muito positivos. Conectando pontos citados aqui, poderíamos até mesmo começar a linkar um gancho para um futuro post. Por isto deixo algumas perguntas: em seu app, quantas imagens você utiliza? Você interage com as mesmas? Hora de utilizar seu senso crítico.
