Rede prática para desenvolvedores Android (parte 1)

Tempo de leitura: 5 minutes

Camada de dados fácil para cada aplicativo

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

Parte 1 – HTTP e camada de rede (o próprio)
Parte 2 – TLS, certificados e fixação
Parte 3 – Autenticadores e Interceptadores
Parte 4 – Desempenho, redundância e simultaneidade
Parte 5 – Teste, simulação e integração

 

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 é abordada, pois a rede no Android é difícil de funcionar, com várias operadoras, diferentes e conteúdo rico, 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 e usando-o, a versão mais bonita da definição é que Http é:

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

Isso significa um monte de coisas, basicamente, se você está construindo um site, aplicativo de smartphone, IoT, 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.

 

As solicitações de Http são geradas 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 fazemos algum clique, talvez uma rolagem ou deleção, por exemplo, imagine o Gmail, toda vez que você entra no aplicativo um Http A solicitação é feita para que os emails sejam atualizados, se você excluir, responder ou até mesmo abrir um email, 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 (Request) – Faça uma solicitação HTTP para um URL
  • Resposta (Response) – a solicitação retornará uma resposta que pode ser um erro ou sucesso.
  • Dados que podem ser analisados (Data that can be parsed) ​​- No celular, precisamos analisar a resposta a um objeto, classe de dados ou estrutura que podemos usar dentro do aplicativo, usando alguns terceiros como Moshi, Json, Gson *, você pode até construir o seu próprio, mas quando chega ao telefone, é uma string simples.

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

POST: originserver/auth 
Content-Type:application/json; chartset=UTF-8 
{ 
  "email": "android@fake.com", 
  "password": "SomeCoolPassword" 
} 

  • Localizador Uniforme de Recursos (Uniform Resource Locator): um URL é um local específico, um endereço em algum lugar da Internet com um tipo específico de método
  • Cabeçalhos (Headers): fornece ao cliente e ao servidor informações adicionais com uma solicitação ou resposta HTTP. Um cabeçalho HTTP consiste em seu nome que não diferencia maiúsculas de minúsculas, seguido por dois pontos (:) e, a seguir, por seu valor.
  • Corpo (Body): 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, recebemos uma resposta, não importa se ela não foi bem-sucedida, temos um código de status para saber disso:

  • 1xx – Está tudo bem, é só esperar um pouquinho
  • 2xx – Está tudo bem, esta é uma resposta totalmente sucessiva
  • 3xx —A resposta está em outro lugar, você está perdido
  • 4xx— A solicitação do cliente foi mal atendida, então este é um erro do lado do celular
  • 5xx – O servidor falhou em atender a uma solicitação correta, então este é 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, são considerados seguros
  • @POST: É usado para a criação de novos recursos. Em particular, é usado para criar recursos subordinados. Não é seguro nem idem potente. 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 é idem potente. Em outras palavras, se você criar ou atualizar um recurso usando PUT e, em seguida, 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 idem potente.

De qualquer forma, qualquer modificação dentro de qualquer um desses métodos para um aplicativo móvel pode ser bastante perigoso, vamos imaginar um aplicativo que recebe uma variável como um duplo em uma resposta, se isso de alguma forma for alterado para um booleano, a análise dos dados será quebrada , 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 são construídos em APIs. Uma API geralmente é um serviço web RESTful (pode ser muitas coisas, é 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 à 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, chamado OkHttpClient, isso irá criar um Client, com readTimeOut e ConnectionTimeOut, se o servidor não entregar nenhuma resposta neste lapso de tempo, acabamos com uma conexão sem sucesso.
Há uma parte realmente importante deste cliente, também podemos colocar um construtor para Cache (e toneladas de outras coisas sobre as quais falaremos mais tarde nesta série)

fun providesOkHttpClient( 
    cache: Cache 
) = { 
  OkHttpClient.Builder() 
        .cache(cache) 
        .connectTimeout(connectTimeOut, TimeUnit.SECONDS) 
        .readTimeout(readTimeOut, TimeUnit.SECONDS) .build() 
} 

 

Cache

Buscar recursos na rede é lento 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 ao seu DNS, por instância, o cache nunca será um substituto para a busca de dados de sua fonte.

Cache de banco de dados (Database Caching)
Não é realmente sobre a camada de rede, nós 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 rendimento, 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 (Content Delivery Network)
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 entregar um cópia do conteúdo de suas APIs, incluindo imagens, streaming e vídeo

Sistema de Nome de Domínio (Domain Name System)
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 de DNS pode ocorrer em muitos 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 o no-cache diretamente no seu construtor de Cache para o seu OkHttpClient, a decisão de fazer este tipo de chamadas é especialmente relacionada ao produto, mais do que ao pov técnico.

CacheControl.Builder().noCache().build()

 

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