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 assunto em questão, certo?

De início, com o conhecimento ainda superficial e provavelmente envolvido em projetos de pequeno porte, há quem não 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 quando trabalhar com UIView ou Layer.

A partir daqui, foca-se no último exemplo citado, onde abordaremos mais detalhadamente e explicitaremos 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, enquanto desenvolvedores, devemos 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, não apenas como exibir o que está ali, mas também como 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 bem suas classes internas (sim, neste caso, o razoável já me satisfaz), 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 utilizarmos um Layer ou uma UIView, um bom ponto de partida é entender onde queremos chegar e qual 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 essa 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 essa 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 começa 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 adicionada ao seu conhecimento, e assim você pode estar se perguntando sobre algumas outras situações onde o que você aprendeu pode ter impactos muito positivos.

Conectando pontos citados aqui, poderíamos até mesmo começar a linkar um gancho para um futuro artigo. Por isto deixo algumas perguntas: em seu app, quantas imagens você utiliza? Você interage com as mesmas? Hora de utilizar seu senso crítico.