Rede prática para desenvolvedores Android (parte 1)

( 7 de novembro de 2020)

Camada de dados fácil para todos os aplicativos

Aqui está a lista dos blogs desta série:

  • ( Parte 1 – HTTP e camada de rede )
  • (Parte 2 – TLS, certificados e fixação)
  • (Parte 3 – Autenticadores e interceptores)
  • (Parte 4 – Desempenho, redundância e simultaneidade)
  • (Parte 5 – Teste e integração)
Rede prática para desenvolvedores Android

Esta é a primeira parte desta série “Rede prática para desenvolvedores Android” quando vamos falar sobre a camada de dados da rede com uma visão diferente que geralmente é o endereço d, porque a rede no Android é difícil de trabalhar, com múltiplas operadoras, conteúdos diferentes e ricos, streaming e tudo isso deve chegar aos nossos usuários sem perder um único detalhe

HTTP e Camada de rede

Http é um protocolo de rede, se você estiver se conectando à internet que o está usando, a versão mais bonita da definição é que Http é:

“Um camada de aplicação protocolo para distribuído, colaborativo, hipermídia sistemas de informação ”

Isso significa um monte de coisas, basicamente, se você estiver construindo um site , aplicativo para smartphone, IoT, até mesmo apenas o download de um arquivo, você está usando este protocolo, ele cresceu de páginas da web com HTML simples para aplicativos da web para aplicativos móveis, evoluiu para se tornar uma camada de API comumente usada.

Http reques Os ts são gerados por nossos usuários à medida que o usuário interage com nosso aplicativo móvel, começamos a solicitar informações de um servidor quando clicamos, talvez uma rolagem ou deleção, por exemplo, imagine o Gmail, toda vez que você insere dentro do aplicativo uma solicitação Http é feito para que os e-mails sejam atualizados, se você deletar, responder ou mesmo abrir um e-mail, isso irá gerar uma solicitação Http, essas solicitações Http vão para um servidor de origem ou um servidor de cache proxy e esse servidor irá gerar uma resposta Http. Normalmente, qualquer conjunto de solicitação / resposta tem:

  • Solicitação – Faça uma solicitação HTTP para um URL
  • Resposta – A solicitação retornará uma resposta que pode ser um erro ou sucesso.
  • Dados que podem ser analisados ​​- No celular, precisamos analisar a resposta a um objeto, dados Classe ou Struct que podemos usar dentro do aplicativo, usando alguns terceiros como Moshi, Json, Gson *, você pode até construir a sua própria, mas quando chega ao telefone, é uma string simples.

Normalmente, qualquer solicitação / resposta Http tem as seguintes coisas:

  • Localizador uniforme de recursos: um URL é um local específico, um endereço em algum lugar na internet com um tipo específico de método
  • Cabeça ers: ao cliente e ao servidor informações adicionais com um HTTP pedido ou resposta. Um cabeçalho HTTP consiste em seu nome que não diferencia maiúsculas de minúsculas seguido de dois-pontos (:) e, em seguida, por seu valor.
  • Corpo: A resposta real, uma string simples que expõe o conteúdo do corpo, pode não ser nada para algum método, mesmo uma Unidade, por exemplo.

Para cada solicitação, obtemos uma resposta, não importa se ela não foi bem-sucedida, temos um código de status para saber:

  • 1xx – Tudo está legal, é só esperar um pouco
  • 2xx – Tudo bem, esta é uma resposta totalmente sucessiva
  • 3xx —A resposta está em outro lugar, você está perdido
  • 4xx— A solicitação do cliente é mal atendido, portanto, é um erro do lado do celular
  • 5xx – O servidor falhou ao atender à solicitação correta, portanto, é um erro do lado do back-end

Métodos HTTP

Existem vários métodos HTTP

  • @GET: É usado para ler ou recuperar informações sobre um recurso. Os pedidos GET são usados ​​apenas para ler dados e não alterá-los, eles são considerados seguros
  • @POST: É usado para a criação de novos recursos. Em particular, é usado para criar recursos subordinados. Não é seguro nem idempotente. Portanto, é recomendado para solicitações de recursos não idempotentes.Fazer duas solicitações POST idênticas provavelmente resultará em dois recursos contendo as mesmas informações.
  • @PUT: É usado para recursos de atualização, PUT-ing para um URI de recurso conhecido com o corpo da solicitação contendo a representação recém-atualizada do recurso original. PUT não é uma operação segura, pois modifica (ou cria) o estado do servidor, mas é idempotente. Em outras palavras, se você criar ou atualizar um recurso usando PUT e depois fazer a mesma chamada novamente, o recurso ainda estará lá e ainda terá o mesmo estado da primeira chamada.
  • @DELETE: É usado para excluir um recurso identificado por um URL.
  • @PATCH: É usado para modificar recursos. A solicitação PATCH precisa conter apenas as mudanças no recurso, não o recurso completo. PATCH não é seguro nem idempotente.

De qualquer forma, qualquer modificação dentro de qualquer um desses métodos para um aplicativo móvel pode ser significativamente perigoso, permite imaginar um aplicativo que recebe uma variável como um duplo em uma resposta , se isso for alterado de alguma forma para um booleano, a análise dos dados será interrompida, essa é uma grande armadilha que os engenheiros de back-end devem levar em consideração sempre que alteram um endpoint que está sendo consultado na produção.

HttpClient

Hoje, a maioria dos aplicativos Android é baseada em APIs. Uma API geralmente é um serviço da web RESTful (pode ser várias coisas, este é apenas um exemplo) que pode ser acessado via HTTP e expõe recursos que permitem ao usuário interagir com o aplicativo, principalmente precisamos de um HttpClient para fazer o acesso para a Internet e comece a buscar dados para nossos usuários.

Dentro do Android, temos uma biblioteca incrível que cria um HttpClient em alguns segundos, chamada OkHttpClient , isso criará um Cliente, com readTimeOut e ConnectionTimeOut, se o servidor não entregar nenhuma resposta nesse lapso de tempo, terminamos com uma conexão malsucedida.
Há uma parte realmente importante de neste cliente, também podemos colocar um construtor para Cache (e várias outras coisas sobre as quais falaremos mais tarde nesta série)

Cache

A busca de recursos pela rede é lenta e caro, o principal motivo é que dependemos de várias coisas no celular, por exemplo, da rede em que nosso usuário está, de 5G a 3G, de WIFI com Fibra Ótica a cabos de comunicação

O cache é projetado para tornar as chamadas de rede melhores para todos, até mesmo para os usuários, pois elas serão encerradas sem solicitações de rede desnecessárias. A captura nunca substituirá uma chamada original para seu DNS, por instância, o cache nunca será um substituto para a busca de dados de sua fonte.

Cache de banco de dados
Na verdade não é sobre a camada de rede, perguntamos às nossas APIs sobre as informações e as armazenamos dentro de SharedPreferences, DataStore ou qualquer banco de dados que pode ser relacional ou não relacional. O desempenho, tanto em velocidade quanto em taxa de transferência, que seu banco de dados fornece pode ser o fator de maior impacto no desempenho geral de seu aplicativo.

Rede de distribuição de conteúdo
Quando o tráfego do seu servidor é mundial, nem sempre é um método fácil e econômico para replicar toda a sua infraestrutura em todo o mundo e, para isso, temos CDN que lhe dá a capacidade de utilizar sua rede global de pontos de presença para fornecer uma cópia em cache do conteúdo de suas APIs, incluindo imagens, streaming e vídeo

Sistema de nomes de domínio
Cada solicitação de domínio feita na Internet consulta essencialmente os servidores de cache DNS para resolver o endereço IP associado ao nome de domínio. O cache DNS pode ocorrer em vários níveis, incluindo no sistema operacional, por meio de ISPs e servidores DNS.

Para a rede especificamente, podemos fazer nosso HttpClient lidar com Cache (verifique o código acima) e Não-Cache, por exemplo em alguns aplicativos, podemos ter um puxão para atualizar, pode ser necessário pular o cache e buscar dados diretamente do servidor. Para forçar uma atualização completa, adicione no-cache diretamente em seu criador de cache para seu OkHttpClient, a decisão de fazer este tipo de chamadas é especialmente mais relacionada ao produto do que ao pov técnico.

Isso é tudo para esta parte da postagem . Para a próxima parte, discutiremos Certificados, Pinning e TSL!

Se precisar de ajuda:

Fico sempre feliz em ajudar, você pode me encontrar aqui:
Médio como
Twitter como @ddinorahtovar
StackOverflow como Dinorah Tovar

Boa codificação! 👩🏻‍💻