Android View: Prólogo
Uma breve introdução sobre o principal componente de UI do Android.
Esse é o ínicio de uma série de artigos com o objetivo de disseminar o conhecimento a respeito do principal elemento de UI do Android: a View.
Ao final dessa série você estará apto a criar componentes customizados sem depender de uma biblioteca de terceiros, e também terá uma boa visão de como o componente base do android funciona.
View… o que é isso? 🤔
É o componente base de construção de elementos visuais a nível de aplicação.
Quando comecei a desenvolver para Android, a minha visão sobre View era bem limitada, eu não entendia ou pelo menos não buscava entender a real utilidade desse componente e como ele estava presente em quase tudo o que eu fazia, mesmo que indiretamente.
A título de informação, esse componente tem mais de 30 mil linhas de código… 🏃♂
Principais características
- Está presente em uma camada () mais inferior que widgets () e activities ou fragments ()
- Possui um ciclo de vida próprio que não está conectado com o ciclo de vida de uma Activity ou Fragment.
Essa segunda característica significa que ele não está fortemente ligado à um Activity (ou Fragment) assim como um Fragment está ligado à uma Activity.
Presença 😎
Sem exagero nenhum ela é o do Android UIniverse.
Como podemos ver na imagem acima, ela está presente em todos os componentes do Android, direta ou indiretamente. Sim, o muito famoso ViewGroup também é uma sub-classe direta dela.
A respeito do ViewGroup, não falaremos muito dele nessa série, mas saiba que ele é bastante utilizado em Containers ou Layouts como: RelativeLayout, LinearLayout, FrameLayout e ConstraintLayout, pois sua função é fazer uma agrupagem de Views.
A pilha do Android… 🔋
A plataforma Android tem toda uma pilha bem definida e eu recomendo bastante que você leia mais sobre ela nessa página: .
O conteúdo da página é bem interessante e ela explica cada parte dessa pilha e como elas estão presentes na plataforma. O mais interessante pra gente, no momento, é a segunda camada (de cima para baixo), que é o Android Framework.
A imagem é muito interessante por causa da descrição que ela exibe para cada camada. A segunda, contém a seguinte mensagem:
Managers (Activity, Notification, Resource, …) — View System
Que mostra que o view system do Android, que incorpora os pacotes e , está separado do managers, que contém e .
Mas o que isso realmente quer dizer? 😡
Que o Framework também está dividido em sub camadas, e elas estão organizadas de um modo em que a mais profunda não possui uma dependência com uma mais externa. Um exemplo disso é o seguinte:
As três camadas acimas estão em nível de profundidade. A última (android.view) não realiza uma comunicação com a primeira (android.app) ou com a segunda (android.widget). Mas a segunda (android.widget) utiliza bastante da última camada, afinal é nessa camada onde estão presentes os diversos componentes de UI que nós utilizamos hoje: TextView, Buttons, RelativeLayout, Spinner.
“[…] Do modo como o Android (Framework) está dividido hoje, onde cada camada está no topo de uma outra, você pode, por exemplo, se livrar da camada android.widget e só utilizar a android.view e tudo vai funcionar.” — .
O interessante da frase acima dita pelo serve para entendermos que para construirmos nossos aplicativos nós não dependemos do UI Toolkit (Widgets + Material Components), nós podemos simplesmente utilizar apenas a camada android.view, se caso quisermos fazer isso — ou se formos loucos o suficiente.
Indo direto ao ponto. 🚍
Hoje no Android nós temos uma série de componentes de UI que estão presente na camada android.widget, e são eles que nós utilizamos para compor nossas telas.
A real é que, em algum momento, você vai precisar utilizar um componente que não está presente no Framework ou nos componentes do .
E é aí que entram dois conceitos bem legais: Custom e Compound Views.
Custom Views
A definição para esse tipo é que eles são criados a partir do componente base (View) e definem um comportamento próprio.
Exemplo: TextView é uma Custom View, mas o Button não.
Compound Views
São componentes que herdam de outros componentes e utilizam comportamentos padrões definidos por eles.
Exemplo: O Button é uma Compound View, pois ele utiliza a TextView como base para o seu comportamento relacionados a texting.
Exercite: vá ao Framework do Android e tente dizer quais componentes são Custom e quais são Compounds.
Ainda sobre Custom Views… 🛂
Ao longo dessa série nós veremos mais sobre Custom Views e iremos criar algumas, mas antes de continuarmos, vamos abordar algumas vantagens e desvantagens que estão presentes na criação de Custom Views.
- Pode ser doloroso ou demorado se você for iniciante ou não conhecer muito bem o view system.
Eu gosto de acreditar que se queremos crescer, a gente precisa apanhar um pouco, e Custom Views baterão em nós, no entanto, no fim, será prazeroso conseguir criar nossas próprias custom views sem depender de terceiros.
- Temos liberdade de criação.
Essa é a principal vantagem de criar uma Custom View: temos independência e podemos criar o que quisermos, mas precisamos nos preocupar com algumas coisas (veremos mais sobre isso nos próximos artigos 🕵️♀️).
implementation 'fulano:componente:ftw'é mais rápido… 🤷♀️
É verdade, é bem mais rápido utilizar o componente que alguma pessoa adorável criou para o bem da comunidade. Mas você precisa lidar com os seguintes problemas, licenças e o principal: você está criando uma dependência externa e isso é ruim. E se você precisar de um comportamento que o componente não possui? E se o autor da biblioteca simplesmente desistir de atualizar ela?
Outro problema que muita gente deve ter: gráficos! O android não possui um componente padrão para gráficos e isso é chato! Desenhar gráficos é algo chato e então cedemos para uma biblioteca de terceiro.
Mas isso também tem um problema: a tal biblioteca possui uma quantidade enorme de gráficos, mas você só vai usar um tipo… será que você não está importando código desnecessário? 😱
- Podemos criar um componente customizado apenas utilizando os já existente da plataforma.
Sim, conseguimos, por exemplo, criar um indicador de páginas (aquele redondinho) apenas criando ImageViews que possui dois estados: selecionado e não selecionado.
O primeiro representa uma bolinha com uma cor ativa e mostra ao usuário a página atual que ele está visualizando no ViewPager, o segundo são as outras páginas inativas.
Ou seja, para 3 páginas no ViewPager eu tenho ‘bolinhas’ e a página atual terá uma bolinha com alguma cor ou tamanho diferente. E olha só, basta jogar essas 3 ImageViews dentro de um LinearLayout com orientação horizontal e…. feito!
Eu já fiz isso… mas diga-me, será mesmo que é performático usar uma quantidade dinâmica de ImageViews para isso? A resposta é não, essa abordagem é provavelmente a pior opção.
Conclusão 👀
Assim, esse artigo introduziu um pouco sobre a View ou One Above All que está presente nesse UIniverse do Android, e como o Framework lida com ela.
Nós próximos artigos iremos nos aprofundar mais nessa entidade, e sim, essa série é só sobre View e iremos passar por todo um processo de conhecer o comportamento dela, como criar até chegar em customizações mais avançadas como animações. Também teremos uma outra série dedicada a um carinha muito carismático: o Canvas. 🎨
Referências
Esse artigo é fortemente inspirado na comunidade e em desenvolvedores notáveis como: e .
Próximo episódio
Se esse artigo te deixou com alguma dúvida, não hesite em perguntar ou se preferir você pode entrar em contato comigo nas seguintes redes sociais:
Twitter:
LinkedIn:
Android View will return.
