Explique como eu sou júnior III – Componentes de arquitetura do Android

Hadi Tok Seg. 8 de jul · 6 min ler

Nesta série, tenho falado sobre os problemas com o desenvolvimento do Android e as coisas que usamos para resolvê-los. Eles eram problemas crônicos e alguns deles são resolvidos pela comunidade. Eu acho que no momento em que o Google estava ocupado resolvendo problemas do lado do usuário. Melhorias nas ferramentas de desenvolvimento foram limitadas. Lançamento do Android Studio aliviou um pouco da dor, mas havia outros problemas.

Cerca de dois anos atrás, o Google lançou o primeiro componente de arquitetura do Android, o Lifecycle . Desde então, mais componentes de arquitetura do Android (AAC) são lançados para resolver diferentes problemas. Eu acho que eles têm fácil de usar, bem pensado api. Eles também trabalham muito bem juntos. A coisa ruim sobre eles é que alguns deles não deveriam existir e alguns deles deveriam fazer parte do sistema operacional Android, em primeiro lugar, em vez de serem bibliotecas externas. Eles são uma camada acima de partes problemáticas do sistema. Os problemas estão lá, mas se você usar os componentes de arquitetura, você pode evitar lidar com esses problemas. Usar o AAC exige uma nova camada de conhecimento sobre o desenvolvimento de aplicativos Android na maioria das vezes.

Eu acho que falei sobre o LiveData e ViewModel com detalhes suficientes na primeira e segunda partes desta série, então eu não cobrirei os componentes Lifecycle e ViewModel neste post. Vamos ver quais outros componentes temos em uma ordem de familiaridade para mim:

Navegação

Eu acho que a navegação é a minha favorita. Na CitizenMe, começamos a usar a navegação quando introduzimos novas telas de login e registro com o link mágico. A melhor parte disso é; ele impede que você use transações desagradáveis do Fragment se você usar vários fragmentos com uma única atividade. Transações de fragmentos foram meu pesadelo no desenvolvimento do Android. Mesmo que eu saiba exatamente como eles funcionam, há alguns casos que não posso implementar sem passar muito. Eu acho que posso escrever uma postagem completamente nova sobre problemas com fragmentos e fragmentar transações, mas vou adiar por enquanto e apenas aconselhar os desenvolvedores juniores a usar isso em vez de tentar descobrir como as transações de fragmentos funcionam.? No momento, você não pode realmente fazer porque as transações de fragmentos são provavelmente usadas na maioria dos aplicativos Android atuais.

Com o componente de navegação, você tem controle suficiente para fazer as coisas necessárias sem ter que lidar com muitos detalhes. Você pode conferir o guia do desenvolvedor de navegação para ver as coisas que ele pode fazer e acho que ele pode atender tudo que ele oferece de maneira adequada. Se você observar os benefícios que oferece, poderá concluir os problemas reais da navegação Android sem usá-los.

Ligação de dados

Nos primórdios do desenvolvimento do Android para acessar as visualizações em um arquivo de layout XML do código java, precisávamos usar o findViewById(id:Int) para cada visualização única. Isso introduziu muito código clichê. Mais tarde, bibliotecas como o Android Annotations e o Butterknife apareceram e nos ajudaram a evitar o findViewById(id:Int) e usar anotações para fazer esse trabalho. O Google decidiu abordar esse problema com uma abordagem diferente. Com Ligação de Dados, você pode vincular dados a visualizações das definições XML das visualizações, em vez de localizar exibições. Portanto, é o oposto de encontrar exibições e definir as propriedades das exibições.

Eu acho que a melhor coisa sobre vinculação de dados é que ele pode vincular as visualizações ao LiveData, de modo que quando ele é atualizado, a visualização é atualizada automaticamente. Embora seja uma biblioteca legal, sou a favor de usar o Kotlin Android Extensions View Binding porque é mais fácil e mais limpo de usar.

WorkManager

Nos bons e velhos tempos, tínhamos Service (ainda temos) para fazer as coisas em segundo plano sem sermos afetados pelos ciclos de vida das atividades. Combinando-os com o BroadcastReceiver e o AlarmManager , poderíamos agendar as coisas para acontecer, mesmo que o aplicativo não esteja funcionando em primeiro plano. O que pode dar errado certo? Acabou muito. Isso permitiu que os desenvolvedores acordassem o dispositivo a qualquer momento e isso fazia com que os aplicativos esgotassem a bateria e os dados sem quaisquer restrições. Em 19 e 23 restrições de antecedentes da API do Android colocadas em prática. Essas restrições fizeram com que os aplicativos não funcionassem corretamente e novas ferramentas introduzidas para o trabalho em segundo plano não eram compatíveis com versões anteriores. Para corrigir este problema, o WorkManager é introduzido. O WorkManager lida com trabalhos com as ferramentas disponíveis no nível da API. Ele também permite que os desenvolvedores tenham restrições, como conectividade e status de cobrança, para executar as tarefas.

Sala

Room é um dos componentes que eu não tenho chance de usar, mas estou ansioso para usá-lo. Tem uma API semelhante ao Jdbi, que é uma das minhas bibliotecas favoritas em Java. Room fornece uma API sobre o SQlite para um acesso mais robusto ao banco de dados. Isso nos poupa do problema de lidar com cursores e criar objetos Data. Tudo o que precisamos para fornecer interfaces com funções tomando parâmetros de consulta com anotações fornecendo consultas SQlite. Toda a implementação e execução é feita por nós, o que é sempre ótimo.

Paginação

Carregar grandes quantidades de dados na memória não é ideal em um dispositivo móvel. Leva mais tempo para buscar de um banco de dados ou uma API, leva mais tempo para desserializar dados e usa mais memória. Portanto, é uma boa ideia buscar dados suficientes para mostrar e solicitar mais quando necessário. No Android com RecyclerView isso foi feito escutando rolagem com OnScrollListener e solicitando próximo lote de dados que poderia ser difícil se você não sabe o que está fazendo. Com Paging isso é muito mais fácil.