Android com Kotlin: comunicação com Web API

Conhecendo o projeto Android e Web API - Apresentação

Opa, pessoal! Beleza?

Eu sou Alex Felipe, instrutor aqui da Alura, e vou apresentar para vocês o curso de Android com Kotlin: Comunicação com Web API.

A partir deste curso, eu vou assumir que vocês tenham alguns conhecimentos como pré-requisitos, que serão apresentados no curso de Android com Kotlin: Migrations e relacionamento com o Room. Então vou presumir que vocês sabem o que é uma migration e como implementá-la.

As Migrations serão um recurso que utilizaremos bastante neste curso, dado que faremos diversas mudanças, entendendo passo a passo quais são os desafios que temos durante a comunicação com Web API. Terão outros assuntos, como coroutines, que também são apresentados, então vou deixar bem claro, nos pré-requisitos, tudo que vocês precisam saber.

Agora que passei pelos pré-requisitos, eu vou focar nos pontos que exploraremos neste curso. O primeiro deles será o projeto que utilizaremos e o cenário que trabalharemos dentro dele.

O projeto é chamado de Ceep. Eu vou oferecê-lo para vocês baixarem, porque ele será considerado o projeto-base.

A ideia dele é permitir que nós gerenciemos notas. Isso significa que podemos criar, alterar, remover e visualizar todas as alterações nas nossas notas.

Por exemplo, criei esta primeira nota, que tem uma imagem com aplicativos, o título "Estudar Android" e a descrição "Como criar o primeiro App". Eu tenho outras notas também.

A nota com o título "Estudar sobre API" tem como descrição "Como consumir e implementar Api no Android". A última nota tem o título "Estudar para a prova", com os estudos que preciso fazer para minhas provas, que são, "Cálculo, Banco de dados, Arquitetura, Apps Mobile, Teoria de grafos, Machine Learning".

Poderíamos colocar diversas informações. Inclusive, se clicarmos na nota, o teclado aparece para fazermos adições.

O que eu quero deixar claro em relação a este aplicativo é que ele está, neste momento do projeto inicial, implementado com o Room. Existe uma característica muito importante de notarmos em uma implementação apenas com o Room, que mostrarei a seguir.

Acessaremos as informações do aplicativo, indo até a lista de aplicativos e abrindo o "App info" do Ceep. Se desinstalarmos o app ou limpamos o armazenamento dele, que será o que vou fazer agora, ao abrirmos o aplicativo novamente, notaremos que perdemos todas as informações.

Tudo o que anotamos e todo o nosso progresso, desde o começo do uso do nosso aplicativo, não podem mais ser recuperados. Portanto, se tivéssemos anotações muito importantes, como os estudos para a prova, não saberíamos o que fazer, porque o aplicativo não apresentaria com critério de confiança.

Então tenham consciência de que, ao utilizarem o Room como única maneira de armazenamento de informações, o seu aplicativo tem este sério problema. Caso o usuário limpe os dados do aplicativo, perca o celular, precise formatar ou qualquer ação que apague as informações do app, não é possível recuperá-las.

Porém, aprenderemos que, a partir da comunicação com a Web API, é possível recuperar essas informações. Dado que uma Web API é um serviço online, conseguimos recuperar essas informações a partir do acesso à Internet. Basta fechar o aplicativo e abri-lo novamente para, através da chamada, ele recuperar as informações. Isso porque temos uma Web API dedicada a salvar essas informações para nós.

Agora vocês devem estar se perguntando o que é uma Web API e como ela consegue fazer essa recuperação. A Web API é um serviço externo, ou seja, uma aplicação Web que fica rodando na Internet e mantém as informações dos nossos aplicativos.

Inclusive, esta é uma solução bastante comum em vários aplicativos, como os de mensagens, redes sociais e vídeos. Onde conseguimos acessar conteúdos online, muito provavelmente tem uma Web API oferecendo este recurso para nós. Por exemplo, se usamos um aplicativo, realizamos várias ações nele e, ao acessá-lo de outro dispositivo, ele contém as mesmas informações, é porque existe uma Web API disponível para isso.

Então, entenda, este conteúdo é extremamente importante no seu desenvolvimento como Dev Android. O que você aprenderá será um passo muito importante para você evoluir na usa carreira.

Agora que eu passei essa parte do produto que iremos explorar durante este curso, envolvendo toda esta comunicação complexa, vou explicar sobre as partes mais técnicas que aprenderemos.

Inicialmente entenderemos o que é uma Web API e utilizaremos nossa própria Web API, via spring boot, para salvarmos as informações. Também descobriremos como nos comunicar com essa Web API através do Retrofit, que é uma biblioteca para fazer uma comunicação via HTTP.

Aprenderemos como organizar nosso código que busca informações na Web API e no nosso banco de dados. Neste momento, deveremos tomar cuidado e usar estratégias específicas para manter a integridade das informações do nosso usuário.

Entenderemos, também, como manusear nosso aplicativo tanto offline, quanto online, para depois fazermos a sincronização. De maneira geral, este é um ponto bem complicado dentro de soluções de software. Nós exploraremos uma das situações possíveis para entendermos este funcionamento.

Portanto, será bastante conteúdo e informações. Eu apresentei alguns pontos específicos, mas existem outros detalhes que aprenderemos.

Espero que estejam animados e animadas para o curso. Conto com a presença de vocês na primeira aula.

Gostou?

Então vamos começar!

Conhecendo o projeto Android e Web API - Apresentando o projeto

Antes de começarmos a estudar a comunicação com a API, é muito importante conhecermos o nosso projeto.

Eu vou aproveitar este momento para introduizir para vocês o projeto que utilizaremos durante este curso, para conhecerem as funcionalidades e detalhes das implementações. Assim conseguirão acessar o projeto, testar e, quando tiverem mais familiaridade com ele, começaremos com o conteúdo do curso.

Inicialmente, o que precisamos saber do projeto? O nome dele é Ceep e ele tem a proposta de gerenciar notas. Se considerarmos o contexto atual, e pegarmos aplicativos do nosso dia a dia, ele vem com a proposta de simular o Google Keep, que é um aplicativo da Google com a mesma funcionalidade.

Sabendo disso, vamos analisar nosso projeto. Quando acessarem este projeto e executá-lo pela primeira vez, ele terá, inicialmente, essa tela em branco com duas informações.

A primeira está no centro da tela em cinza, escrito "Sem notas", indicando que não temos nenhuma nota. Além disso, no canto inferior direito temos um float action button ciano, com "CRIAR NOTA" escrito dentro dele, indicando uma ação para criarmos uma nota.

Como podemos perceber, este float action button é uma versão personalizada do que trabalhamos anteriormente, que era apenas um círculo. Neste, temos a opção para adicionar texto, no qual eu escrevi o "CRIAR NOTA". O nome desta versão é float action button extended.

Se quiserem utilizá-lo, fiquem à vontade para ver como ele foi implementado no arquivo de layout e para usar este float action button no projeto de vocês.

Dado que passei essa informação inicial, tem um ponto muito importante que eu informarei a vocês, que é a versão do Android Studio que eu estou utilizando. Na barra de navegação superior da janela, clicamos em "Help > About".

Aparece a tela de apresentação do Android Studio e, neste momento, é muito importante descobrirem a versão que vocês estão usando. Desta forma, garantimos que os aspectos visuais que veremos durante o curso sejam os mesmos no momento em que vocês estiverem estudando.

Então, durante o curso, esta foi a versão mais recente que eu tive acesso ao baixar o Android Studio, que é a Android Studio Bumblebee |2021.1.1 Patch 1. Eu recomendo que vocês utilizem esta mesma versão.

Se preferirem, podem utilizar uma versão mais atualizada, mas se notarem algo diferente e quiserem manter exatamente o que verão durante o curso, eu recomento que voltem para esta versão. Portanto, é importante que estejam cientes disso para, caso surja algo diferente do curso, vocês saberem que pode ser por causa da versão.

Outro ponto relevante é que, durante o curso, eu estou utilizando um emulador com uma versão diferente da que utilizamos em outros conteúdos. Este tem a versão 12 do Android, como vou mostrar para vocês acessando "Settings > System > System Update". Portanto, se quiserem manter o mesmo visual deste emulador, precisam desta versão também.

Como podem ver, nesta versão não temos os botões na barra inferior do aparelho, onde tinha o Home, o botão de Voltar, que é o Back e o botão para vermos as tarefas que estão em execução.

Para fazermos isso, existem alguns gestos. Por exemplo, se queremos voltar, nós clicamos no centro da lateral direita da tela e arrastamos para esquerda.

Quando fazemos isso, aparece uma seta apontando para esquerda. Se apenas segurarmos o clique, nada acontece. Se arrastarmos de volta para direita, nada acontece também, mas se clicarmos, arrastarmos para esqueda e soltarmos, a tela volta.

O mesmo acontece se clicarmos no centro da lateral esquerda e arrastarmos para lateral direita. Aparece uma seta apontando para esquerda e, quando soltamos, a tela volta para anterior. É importante saberem que tem uma área específica nas laterais em que podemos fazer este gesto para conseguirmos voltar. Essa é uma informação importante para terem a mesma funcionalidade.

Então, vamos voltar para o app e descobrirmos as funcionalidades diferentes que temos. Basicamente, para criarmos uma nota, clicamos no float action button e digitamos as informações, que seriam um título e uma descrição.

Por exemplo, vou escrever no título "Minha primeira nota" e, na descrição, "minha primeira descrição". Em seguida, temos alguns menus acessíveis para nós.

No canto direito da barra superior, temos o menu "Salvar", com o "✓" e o menu para "Remover", com o sinal de uma lixeira, mesmo que estejamos inserindo uma nova nota. Depois eu vou explicar sobre isso.

Já no canto inferior direito, temos um botão que permite que adicionemos imagens. Já conhecemos este tipo de formulário de outros conteúdos aqui da Alura, mas se é a primeira vez que você está vendo, é um Dialog em que colocamos um layout personalizado.

Ele é focado em receber imagens e oferecer um suporte para que estas elas sejam carregadas a partir de uma URL. Veremos sobre isso logo mais.

Inicialmente, eu vou cancelar a inserção de imagem e fazer uma nota simples para vermos o resultado. Ao clicarmos em "Salvar", percebemos que nossa nota foi salva e aparece na primeira tela.

Também é possível fazer o gerenciamento das notas, alterando-as ou as removendo. Para alterar, clicamos na nota que criamos e, quando ela abre, conseguimos mudar as informaçõe. Podemos, por exemplo, trocar o título para "Minha primeira nota alterada", assim como mudar a descrição para "minha primeira descrição alterada com mais informações para testar o comportamento de alteração".

Eu coloquei muito texto para vermos como a nota fica na nossa lista. Vou aproveitar este momento para também colocar uma imagem. Eu separei uma imagem do site Pexels, que tem imagens gratuitas, e vou copiar a URL desta imagem.

Voltarei na nota, vou clicar no menu de adicionar imagem, colar a URL e clicar no botão "CARREGAR", que fica logo acima do campo onde colamos a URL, e clicar em "CONFIRMAR". Podemos clicar em "CONFIRMAR" sem pedir para carregar a imagem. O carregamento apenas gera um preview.

Quando confirmamos, temos nossa imagem adicionada ao cabeçalho da nota e, ao clicarmos em salvar, somos direcionados para tela com a lista de notas. Com isso, todas as mudanças que fizemos na nossa nota foram salvas, inclusive a nossa imagem. Portanto, esta é outra funcionalidade acessível que nós temos.

Podemos criar mais de uma nota, então vou criar uma nota de teste apenas com o título. Clicando no botão "CRIAR NOTA", vou preencher o título com "nota de teste" e salvar. Percebemos que, mesmo que tenha apenas o título, ela aparece na lista.

Façamos alguns testes com a adição de imagens. Se abrirmos o menu de imagem e clicarmos em confirmar, sem colocar nenhum link, nada acontece. Entretanto, se colocarmos no campo da URL um "sss", ou seja, uma URL inválida, e clicarmos em confirmar, aparece um círculo com uma exclamação no meio onde ficaria a imagem da nossa nota. Ao salvarmos a nota, este ícone permanece no cabeçalho.

Outro ponto importante é que, uma vez que nossas notas têm conteúdos com tamanhos distintos, temos um aspecto um pouco diferente em relação a outros gerenciadores de layout do próprio Recyclerview. Eu usei uma versão chamada de staggered, que escalona a altura de cada item.

Então, as notas com mais conteúdo ficam maiores até determinado limite. Eu não lembro qual é este limite, mas deve ser, aproximadamente, 200 dpi. Já as notas menores aumentam o mínimo necessário.

Por fim, temos a remoção. Se é uma nota já criada, basta abrirmos e clicarmos em "Remover" que ela será apagada. Quando é uma nota que ainda está sendo criada, ao clicarmos em "Remover", ela tenta apagar, não consegue, então volta para lista de notas.

Foi feito desta forma porque eu reutilizei muitos códigos, então evitei adicionar mais complexidade, como é o caso de esconder o menu "Remover", quando for inserção, e só apresentá-lo quando for uma alteração. Caso queiram, vocês podem fazer isso, mas é válido saberem o motivo para eu ter feito assim, ou seja, para simplificar o código e reutilizá-lo ao máximo.

Isso é o que precisamos saber em relação ao nosso app. O próximo passo é aprendermos sobre o projeto, código, build e assim por diante.

Antes disso, é importante notarem que o projeto tem um GitHub que estará acessível para vocês. Então não precisam se atentar tanto aos nomes que eu mostrei aqui. Vocês terão acesso ao projeto via README e poderão lê-lo com calma.

Para acessarem o projeto, vão até à atividade, onde estará tudo o que precisam.

Conhecendo o projeto Android e Web API - Conhecendo o código

Voltando para o Android Studio, conversaremos mais sobre o nosso projeto.

O primeiro ponto que quero abordar com vocês é sobre o arquivo de build. Ao acessarmos o "build.gradle", teremos dois níveis, sendo o primeiro deles o do projeto.

O que vocês precisam saber sobre o projeto é a versão do Kotlin. Aqui, eu estou utilizando a 1.6.10. Então se quiserem reutilizar alguma parte do projeto, atentem-se a usar a mesma versão, porque pode ter algo que eu utilizei que só funcione bem nessa versão do Kotlin.

Ao nível de projeto, é isso. Vamos agora para o nível de módulo, que é o "build.gradle (:app)". Dentro deste arquivo, teremos diferenças nos plugins, porque estamos utilizando o Room para salvar as informações. Podemos observar isso fechando o app no simulador e abrindo novamente. Percebemos que as informações foram mantidas, porque as estamos salvando com o Room.

Aprendemos previamente que o Room utiliza o conceito do annotation processing, que seria um pós-processador que gera códigos através de metadados. Anteriormente, e por muito tempo, eu usava o kapt, porém, agora temos um substituto mais recente, que é o KSP.

Se acessarmos a página do Kotlin Symbol Processing API, entendemos que o KSP é uma nova API para conseguirmos fazer as mesmas coisas que fazíamos com o kapt. A grande diferença, explicada logo no começo da página, é que, comparado com o kapt, os annotation processors que usam o KSP podem rodar até duas vezes mais rápido.

Por estarmos codando em Kotlin, acessaremos esta ferramenta. Então, se a biblioteca utilizada tem um pós-processador com suporte KSP, o ideal é utilizá-lo, por estas vantagens.

Caso queiram saber a razão do KSP, vocês podem acessar esta página na documentação do Kotlin. Vocês também podem ler as outras páginas sobre KSP nesta documentação para compreenderem mais sobre ele, se faz sentido a substituição do kapt e assim por diante.

Esta era informação que queria passar sobre build e KSP. Temos a mudança do plugin e, ao descermos as informações, perceberemos que, na declaração do processador, agora tem a nomenclatura ksp.

Também a partir deste projeto, estou utilizando o SDK 32, porque ele está disponível no Android Studio, ainda que estejamos usando o Android 12, ou seja, a API 31. Sempre mantenham a versão mais recente!

Como mínima, ainda mantenho a SDK 21. Caso queiram mudar, fiquem à vontade, não há uma restrição quanto a isso.

Percebemos também que o KSP está presente para adicionar mais informações. Portanto, é interessante saberem que agora ele será o responsável por gerar códigos.

Outra informação importante é que estou utilizando a versão 11 do Java, enquanto na maioria dos projetos anteriores eu utilizei a versão 8. Além disso, estamos usando o coroutines, com lifecycle-runtime para termos acesso ao lifecycleScope.

Não tenho tantas novidades referentes às bibliotecas, a não ser o Coil, para carregar as imagens, além das outras bibliotecas que vêm no nosso projeto.

Agora vou aproveitar para fazer alguns comentários em relação ao código. Inicialmente temos o modelo de nota, no arquivo "Nota.kt", e a partir dele que faremos todas as modificações que precisamos. Por exemplo, o próprio Room.

Então temos a "Nota.kt" como @Entidade, a "NotaDao.kt", para fazer as comunicações com o banco de dados, e o "AppDatabase.kt", que configura com o banco de dados com o Dao e a Entidade.

Em seguida, temos as nossas Activities , sendo elas a "ListaNotasActivity.kt", que é a activity inicial, e a "FormNotaActivity.kt", que representa o formulário de criação da nota. Então, se quiserem investigar algum destes códigos, fiquem à vontade para editar e fazer da forma como preferirem.

Para fazer o curso, recomendo que não alterem tanto o projeto, justamente para não acontecer nenhum bug. Sendo assim, não façam alterações até terem estudado e aprendido o conteúdo do curso. Depois vocês poderão personalizar, mudar o tema e fazer o que mais quiserem.

Outra informação que quero passar são implementações, principalmente na "ListaNotasActivity.kt". Nela estou usando um novo recurso chamado repeatOnlifecycle(), que usamos para trabalhar com o flow.

Percebemos que o buscaNotas() utiliza, internamente, o dao, que chama o dao.buscaTodas(){} e este nos entrega um flow, pelo qual buscamos notas, fazemos a visualização delas e assim por diante. Por que precisamos nos preocupar com isso em relação ao flow?

Primeiramente porque o flow tem a característica de servir como um listener, ou seja, como ouvinte. Cada vez que tem uma atualização, ele reexecuta este código. Esta ação de ficar como ouvinte, reexecutando o código, acontece mesmo que não estejamos na nossa tela de lista de notas.

Nem sempre utilizaremos ou atualizaremos este código quando estivermos na tela "Lista de notas". É até possível que estejamos no "Formulário" e o código ainda esteja sendo executado. Isso significa que, com essa implementação do flow, podemos utilizar recursos desnecessariamente, porque não precisamos que o código seja executado a todo momento.

Com o repeatOnLifecycle(Lifecycle.State.STARTED){}, indicando como argumento o estado, que é o STARTED, evitamos isso. Por padrão, quando houver um flow internamente, ele será cancelado ao ser pausado, ou seja, quando uma tela se sobrepor àquela activity.

Então a "Formulário" se sobrepôs à "Lista de Notas" e acionou o pause. Quando pausa, o repeatOnlifecycle(){} para tudo o que está dentro dele, porque reconhece que este estado não pertence à tela visível. Essa é a característica dele, impedindo que o flow tenda ao infinito.

Vocês podem se perguntar se o lifecycleScope não daria conta disso. Ele consegue fazer isso, mas somente no destoy, que só é possível quando acabamos com a activity.

No caso do repeatOnlifecycle(){}, percebemos que, ao sairmos do "Formulário" e voltarmos para "Lista de Notas", ela já está disponível, ou seja, a activity não é totalmente recarregada. Quando volta, ela aciona o STARTED, ao invés do CREATED, e só então ela executa o código dentro do repeatOnlifecycle().

O próprio nome indica isso, que só será repetido no ciclo de vida. Contudo, de forma omitida, ele cancela no pause.

Este é um assunto mais complexo. Caso queiram, tem o artigo repeatOnLifecycle API design story, que eu vou oferecer para vocês nas atividades. Ele explica tudo sobre esta mudança e a importância de usar esta API junto com o flow. Eu tentei resumir as informações, mas no artigo vocês podem encontrar mais explicações e especificidades que deixe tudo mais claro.

Era isso que queria explicar sobre os detalhes. Posso ter deixado de passar por algum ponto com mais clareza, assumindo que já aprenderam em outros conteúdos, mas fiquem à vontade para explorar o código.

Caso queiram comentar alguma implementação feita, utilizem o Fórum e o Discord para conversarmos sobre isso.

Também percebemos que é na "ListaNotasActivity.kt" que acontece a verificação, apresentando a mensagem "Sem notas", o Recycleview e assim por diante. Já no "FormularioNotaActivity.kt", temos a imagem como MutableStateFlow<>, justamente para conseguirmos utilizar o flow em múltiplos lugares e atualizar constantemente. Portanto, é um recurso mais reativo utilizado dentro código.

Por isso, eu recomendo que, cada vez mais, investiguem o que o projeto tem de disponível para conseguirem entendê-lo com mais facilidade. Explorem também outros códigos que eu não foquei, como as extentions e outros possíveis códigos de UI.

O último ponto, para terminarmos, é que este projeto mantém a característica que vimos na introdução do curso. Portanto, se acessarmos as informações do App e limparmos os dados, notaremos que todas as informações serão perdidas. Aprenderemos a lidar com isso nas próximas aulas.

Até já.

Sobre o curso Android com Kotlin: comunicação com Web API

O curso Android com Kotlin: comunicação com Web API possui 258 minutos de vídeos, em um total de 54 atividades. Gostou? Conheça nossos outros cursos de Android em Mobile, ou leia nossos artigos de Mobile.

Matricule-se e comece a estudar com a gente hoje! Conheça outros tópicos abordados durante o curso:

• Conhecendo o projeto Android e Web API
• Utilizando o Retrofit
• Melhorando a integração com a Web API
• Integrando com a Web API
• Sincronizando o app com a Web API