Praktisk nettverk for Android-utviklere (del 1)

( 7. nov 2020)

Enkelt datalag for alle applikasjoner

Her er listen over bloggene i denne serien:

  • ( Del 1 – HTTP og nettverkslag )
  • (Del 2— TLS, sertifikater og pinning)
  • (Del 3— Authenticators and Interceptors)
  • (Del 4 – Ytelse, redundans og samtidighet)
  • (Del 5 – Testing og integrering)
Praktisk nettverk for Android-utviklere

Dette er den første delen av denne serien “Praktisk nettverk for Android-utviklere” når vi skal snakke om nettverksdatalaget med en annen visjon som vanligvis er adressert d, fordi nettverk på Android er vanskelig å arbeide med flere operatører, annerledes og rikt innhold, streaming og alt dette skal komme til brukerne våre uten å savne en eneste detalj

HTTP og Network Layer

Http er en nettverksprotokoll. Hvis du kobler til internett du bruker den, er den vakre versjonen av definisjonen at Http er:

“En applikasjonslag protokoll for distribuert, samarbeidende, hypermedia informasjonssystemer ”

Dette betyr en rekke ting, i utgangspunktet hvis du bygger et nettsted , smarttelefonapp, IoT, til og med bare en nedlasting av en fil, du bruker denne protokollen, den har vokst fra nettsider med enkel HTML til webapplikasjoner til mobilapper, har utviklet seg til å bli et API-lag som ofte brukes.

Http forespørsler ts genereres av brukerne våre når brukeren interagerer med mobilappen vår, vi begynner å be om informasjon fra en server når det klikket, kanskje en rulle eller sletting, for eksempel, forestill deg Gmail, hver gang du skriver inn en app i en HTTP-forespørsel er laget slik at e-postene oppdateres. Hvis du sletter, svarer eller til og med åpner en e-post, vil dette generere en HTTP-forespørsel, disse HTTP-forespørslene går til enten en originalserver eller en proxy-caching-server, og den serveren vil generere et HTTP-svar. Vanligvis har ethvert sett med forespørsel / svar:

  • Forespørsel – Foreta en HTTP-forespørsel til en URL
  • Svar – Forespørselen returnerer et svar som kan være en feil eller suksess.
  • Data som kan analyseres – I mobil må vi analysere svaret på et objekt, data Klasse eller struktur som vi kan bruke i appen, ved hjelp av noen tredjeparter som Moshi, Json, Gson *, kan du til og med bygge din egen, men når den når telefonen, er den en ren streng.

Vanligvis har alle Http-forespørsler / svar de neste par tingene:

  • Uniform Resource Locator: en URL er et bestemt sted, en adresse et sted på internett med en bestemt type metode
  • Head ers: Gir klienten, og serveren sender ytterligere informasjon med en HTTP forespørsel eller svar. En HTTP-topptekst består av navnet som ikke skiller mellom store og små bokstaver etterfulgt av et kolon (:), deretter av verdien.
  • Body: Det faktiske svaret, en enkel streng som avslører kroppsinnholdet, kan ikke være noe for en eller annen metode, til og med en enhet.

For hver forespørsel får vi svar, uansett om det ikke lykkes, har vi en statuskode for å vite det:

  • 1xx – Alt er kult, bare vent litt
  • 2xx – Alt er greit, dette er et svar som er fullt påfølgende
  • 3xx — Svaret er et annet sted, du er tapt
  • 4xx— Forespørselen fra klienten er dårlig oppfylt, så dette er en feil fra den mobile siden
  • 5xx – Serveren klarte ikke å oppfylle en riktig forespørsel, så dette er en feil fra backend-siden

HTTP-metoder

Det er flere HTTP-metoder

  • @GET: Benyttes til å lese eller hente informasjon på en ressurs. GET-forespørsler brukes bare til å lese data og ikke endre dem, de anses som trygge
  • @POST: Benyttes for å lage nye ressurser. Spesielt brukes den til å lage underordnede ressurser. Er verken trygg eller ledig. Det anbefales derfor for ikke-idempotente ressursforespørsler.Å lage to identiske POST-forespørsler vil mest sannsynlig resultere i to ressurser som inneholder den samme informasjonen.
  • @PUT: Benyttes for oppdateringsmuligheter, PUT-ing til en kjent ressurs-URI med forespørselsorganet som inneholder den nylig oppdaterte representasjonen av den opprinnelige ressursen. PUT er ikke en sikker operasjon ved at den modifiserer (eller oppretter) tilstanden på serveren, men den er idempotent. Med andre ord, hvis du oppretter eller oppdaterer en ressurs ved hjelp av PUT og deretter foretar den samme samtalen igjen, er ressursen fortsatt der og har fortsatt samme tilstand som den gjorde med den første samtalen.
  • @DELETE: Brukes til å slette en ressurs som er identifisert av en URL.
  • @PATCH: Brukes for å endre evner. PATCH-forespørselen trenger bare å inneholde endringene i ressursen, ikke hele ressursen. PATCH er verken trygt eller idempotent.

Uansett, enhver endring i noen av disse metodene for en mobilapplikasjon kan være betydelig farlig, lar oss se et program som mottar en variabel som en dobbel i et svar , hvis dette på en eller annen måte blir endret til en boolsk, vil analyseringen av dataene bli brutt, dette er en stor fallgruve som backendingeniører må ta i betraktning hver gang de endrer et endepunkt som blir konsultert ved produksjon.

HttpClient

I dag er de fleste Android-applikasjoner bygget på API-er. En API er vanligvis en RESTful webtjeneste (kan være mange ting, er dette bare et eksempel) som kan nås via HTTP og eksponerer ressurser som lar brukeren samhandle med applikasjonen, for det meste trenger vi en HttpClient for å få tilgang til internett og begynn å hente data til brukerne våre.

Innen Android har vi et utrolig bibliotek som lager et HttpClient på et par sekunder, kalt OkHttpClient , dette vil opprette en klient med readTimeOut og ConnectionTimeOut, hvis serveren ikke leverer noe svar i dette tidsforløpet, ender vi opp med en ikke-vellykket forbindelse.
Det er en veldig viktig del av denne klienten kan vi også sette en builder for Cache (og mange andre ting som vi vil snakke om senere i denne serien)

Cache

Å hente ressurser over nettverket er både tregt og dyrt, hovedårsaken er at vi er avhengige av flere ting i mobil, for eksempel på nettverket brukeren vår har i det, fra 5G til 3G, fra WIFI med optisk fiber til kommunikasjonskabler

Cache er designet for å gjøre nettverkssamtaler bedre for alle, også for brukerne, fordi de slutter uten unødvendige nettverksforespørsler. Fangst erstatter aldri et originalt anrop til DNS-en din, for eksempel vil cachen aldri erstatte henting av data fra kilden.

Database-caching
Handler egentlig ikke om nettverkslaget, vi spør API-ene våre om informasjonen, og vi lagrer dette i SharedPreferences, DataStore eller hvilken som helst database som kan være relasjonell eller ikke-relasjonell. Ytelsen, både i hastighet og gjennomstrømning som databasen din gir, kan være den mest effektive faktoren for applikasjonens samlede ytelse.

Content Delivery Network
Når servertrafikken din er over hele verden, er det ikke alltid en enkel og kostnadseffektiv metode å replikere hele infrastrukturen over hele verden, og for det har vi CDN som gir deg muligheten til å benytt det globale nettverket av kantsteder for å levere en hurtigbufret kopi av API-innholdet ditt, inkludert bilder, streaming og video

Domain Name System
Hver domeneforespørsel på internett spør i hovedsak om DNS-cache-servere for å løse IP-adressen som er tilknyttet domenenavnet. DNS-caching kan forekomme på mange nivåer, inkludert på operativsystemet, via Internett-leverandører og DNS-servere.

For nettverket spesifikt kan vi lage vårt HttpClient-håndtak Cache (sjekk koden ovenfor) og Non-Cache, for eksempel i noen applikasjoner kan det hende at vi prøver å oppdatere, det kan være nødvendig å hoppe over hurtigbufferen og hente data direkte fra serveren. For å tvinge en full oppdatering, legg til no-cache direkte i hurtigbufferbyggeren din for OkHttpClient, beslutningen om å utføre denne typen samtaler er spesielt produktmessig mer enn teknisk klok pov.

Dette er alt for denne delen av innlegget . For neste del vil vi diskutere Sertifikater, Pinning og TSL!

Hvis du trenger hjelp:

Jeg hjelper alltid, du kan finne meg her:
Medium som
Twitter som @ddinorahtovar
StackOverflow som Dinorah Tovar

Happy Coding! 👩🏻‍💻