Praktiskt nätverk för Android-utvecklare (del 1)

( 7 nov 2020)

Enkelt datalager för alla applikationer

Här är listan över bloggarna i denna serie:

  • ( Del 1 – HTTP och nätverkslager )
  • (Del 2— TLS, certifikat och fästning)
  • (Del 3— Authenticators and Interceptors)
  • (Del 4 – Prestanda, redundans och samtidighet)
  • (Del 5 – Testning och integration)
Praktiskt nätverk för Android-utvecklare

Detta är den första delen av denna serie “Praktiskt nätverk för Android-utvecklare” när vi ska prata om nätverksdataskiktet med en annan vision som vanligtvis är adresserad d, orsaka att nätverk på Android är svårt att fungera, med flera bärare, olika och rikt innehåll, streaming och allt detta bör komma fram till våra användare utan att sakna en enda detalj

HTTP och nätverkslager

Http är ett nätverksprotokoll. Om du ansluter till internet använder du det, den vackra versionen av definitionen är att Http är:

“En applikationslager protokoll för distribuerat, samarbete, hypermedia informationssystem ”

Detta innebär en massa saker, i princip om du bygger en webbplats , smartphone-app, IoT, till och med bara en nedladdning av en fil, du använder detta protokoll, det har vuxit från webbsidor med enkel HTML till webbapplikationer till mobilappar, har utvecklats till att bli ett API-lager som vanligtvis används.

Http Reques ts genereras av våra användare när användaren interagerar med vår mobilapp, vi börjar begära information från en server när de gjorde något klick, kanske en rullning eller radering, till exempel, föreställ dig Gmail, varje gång du skriver in en app en HTTP-begäran görs så att e-postmeddelandena uppdateras. Om du tar bort, svarar eller till och med öppnar ett e-postmeddelande kommer detta att generera en Http-begäran, dessa Http-förfrågningar går till antingen en originalserver eller en proxy-caching-server och den servern kommer att generera ett HTTP-svar. Vanligtvis har varje uppsättning begäran / svar:

  • Begäran – Gör en HTTP-begäran till en URL
  • Svar – Begäran returnerar ett svar som kan vara ett fel eller framgång.
  • Data som kan analyseras – I mobil måste vi analysera svaret på ett objekt, data Klass eller struktur som vi kan använda inuti appen, med vissa tredje parter som Moshi, Json, Gson *, du kan till och med bygga din egen, men när den når telefonen är den en vanlig sträng.

Vanligtvis har alla Http-förfrågningar / svar nästa par saker:

  • Uniform Resource Locator: en URL är en specifik plats, en adress någonstans på internet med en specifik typ av metod
  • Huvud ers: Ger klienten och servern skickar ytterligare information med en HTTP begäran eller svar. En HTTP-rubrik består av dess skiftlägeskänsliga namn följt av ett kolon (:), sedan av dess värde.
  • Body: Det faktiska svaret, en enkel sträng som exponerar kroppsinnehållet, kan inte vara något för någon metod, till och med en enhet till exempel.

För varje förfrågan får vi svar, oavsett om det inte lyckas, vi har en statuskod för att veta det:

  • 1xx – Allt är coolt, vänta bara lite
  • 2xx – Allt är bra, det här är ett svar som är fullt på varandra
  • 3xx —Svaret är någon annanstans, du är förlorad
  • 4xx— Kundens begäran är dåligt uppfyllda, så detta är ett fel från den mobila sidan
  • 5xx – Servern kunde inte uppfylla en korrekt begäran, så detta är ett fel från backend-sidan

HTTP-metoder

Det finns flera HTTP-metoder

  • @GET: Används för att läsa eller hämta information om en resurs. GET-förfrågningar används endast för att läsa data och inte ändra dem, de anses vara säkra
  • @POST: Används för att skapa nya resurser. I synnerhet används den för att skapa underordnade resurser. Är varken säker eller idempotent. Det rekommenderas därför för icke-idempotenta resursförfrågningar.Att göra två identiska POST-förfrågningar kommer sannolikt att resultera i två resurser som innehåller samma information.
  • @PUT: Används för uppdateringsfunktioner, PUT-till en känd resurs-URI med begärande organ som innehåller den nyligen uppdaterade representationen av den ursprungliga resursen. PUT är inte en säker åtgärd genom att den ändrar (eller skapar) tillstånd på servern, men den är idempotent. Med andra ord, om du skapar eller uppdaterar en resurs med PUT och sedan ringer samma samtal igen, är resursen fortfarande kvar och har fortfarande samma tillstånd som den gjorde vid det första samtalet.
  • @DELETE: Används för att radera en resurs som identifierats av en URL.
  • @PATCH: Används för att ändra kapacitet. PATCH-begäran behöver bara innehålla ändringarna i resursen, inte hela resursen. PATCH är varken säker eller idempotent.

Vad som helst, någon ändring i någon av dessa metoder för en mobilapplikation kan vara betydande farlig, låter bilden av en applikation som tar emot en variabel som en dubbel i ett svar , om detta på något sätt ändras till en boolean, kommer analyseringen av data att brytas, det här är en enorm fallgrop som backendingenjörer måste ta hänsyn till varje gång de ändrar en slutpunkt som konsulteras vid produktionen.

HttpClient

Idag bygger de flesta Android-applikationer på API: er. Ett API är i allmänhet en RESTful webbtjänst (kan vara många saker, är detta bara ett exempel) som kan nås via HTTP och exponerar resurser som gör att användaren kan interagera med applikationen, mestadels behöver vi en HttpClient för att få åtkomst till internet och börja hämta data för våra användare.

Inuti Android har vi ett otroligt bibliotek som skapar en HttpClient på några sekunder, kallad OkHttpClient , detta kommer att skapa en klient, med en readTimeOut och ConnectionTimeOut, om servern inte levererar något svar i denna tidsfördröjning, slutar vi med en anslutning som inte lyckas.
Det finns en riktigt viktig del av den här klienten kan vi också sätta en byggare för Cache (och massor av andra saker som vi kommer att prata om senare i denna serie)

Cache

Att hämta resurser via nätverket är både långsamt och dyrt, den främsta anledningen är att vi är beroende av flera saker i mobilen, till exempel på nätverket som vår användare är i, från 5G till 3G, från WIFI med optisk fiber till kommunikationskablar

Cache är utformad för att göra nätverkssamtal bättre för alla, även för användarna, för de kommer att avslutas utan onödiga nätverksförfrågningar. Fångning ersätter aldrig ett originalsamtal till din DNS, per instans, kommer cachen aldrig att ersätta att hämta data från källan.

Databascaching
Handlar egentligen inte om nätverkslagret, vi frågar våra API: er om informationen och vi lagrar den i SharedPreferences, DataStore eller någon databas som kan vara relationell eller icke-relationell. Prestandan, både i hastighet och genomströmning som din databas ger, kan vara den mest påverkande faktorn för din applikations övergripande prestanda.

Content Delivery Network
När din servertrafik är över hela världen är det inte alltid en enkel och kostnadseffektiv metod att replikera hela din infrastruktur över hela världen, och för det har vi CDN som ger dig möjlighet att utnyttja sitt globala nätverk av kantplatser för att leverera en cachad kopia av ditt API-innehåll, inklusive bilder, streaming och video

Domain Name System
Varje domänförfrågan som görs på internet frågar i huvudsak DNS-cacheservrar för att lösa IP-adressen som är associerad med domännamnet. DNS-cachning kan förekomma på många nivåer inklusive på operativsystemet, via internetleverantörer och DNS-servrar.

För nätverket specifikt kan vi göra vårt HttpClient-handtag Cache (kontrollera koden ovan) och Non-Cache, till exempel i vissa applikationer kan vi dra nytta av att uppdatera det kan vara nödvändigt att hoppa över cachen och hämta data direkt från servern. För att tvinga en fullständig uppdatering, lägg till no-cache direkt i din Cache-byggare för din OkHttpClient, beslutet att göra den här typen av samtal är speciellt produktmässigt mer än tekniskt sett. / p>

Detta är allt för denna del av inlägget . För nästa del kommer vi att diskutera Certifikat, Pinning och TSL!

Om du behöver hjälp:

Jag hjälper alltid gärna till, du hittar mig här:
Medium som
Twitter som @ddinorahtovar
StackOverflow som Dinorah Tovar

Glad kodning! 👩🏻‍💻