Rețea practică pentru dezvoltatorii Android (partea 1)

( 7 noiembrie 2020)

Strat de date ușor pentru fiecare aplicație

Iată lista blogurilor din această serie:

  • ( Partea 1 – HTTP și Network Layer )
  • (Partea 2 – TLS, certificate și fixare)
  • (Partea 3 – Autentificatori și interceptori)
  • (Partea 4 – Performanță, redundanță și concurență)
  • (Partea 5 – Testare și integrare)
Rețea practică pentru dezvoltatorii Android

Aceasta este prima parte a acestei serii „Rețea practică pentru dezvoltatorii Android” când vom vorbi despre stratul de date al rețelei cu o viziune diferită care este de obicei adresată d, deoarece rețeaua pe Android este dificil să o funcționeze, cu operatori multipli, conținut diferit și bogat, streaming și toate acestea ar trebui să ajungă la utilizatorii noștri fără a pierde niciun detaliu

HTTP și Network Layer

Http este un protocol de rețea, dacă vă conectați la internet, îl utilizați, versiunea frumoasă a definiției este că Http este:

„Un strat de aplicație protocol pentru distribuire, colaborare, hypermedia sisteme de informații ”

Aceasta înseamnă o grămadă de lucruri, practic, dacă creați un site web , aplicație pentru smartphone, IoT, chiar și doar o descărcare a unui fișier, utilizați acest protocol, a crescut de la pagini web cu HTML simplu la aplicații web la aplicații mobile, a evoluat pentru a deveni un strat API care este utilizat în mod obișnuit.

Http reques ts sunt generate de utilizatorii noștri pe măsură ce utilizatorul interacționează cu aplicația noastră mobilă, începem să solicităm informații de la un server atunci când se face un clic, poate un scroll sau o ștergere, de exemplu, imaginați-vă Gmail, de fiecare dată când introduceți în aplicație o solicitare Http este făcut astfel încât e-mailurile să fie reîmprospătate, dacă ștergeți, răspundeți sau chiar deschideți un e-mail, acest lucru va genera o solicitare Http, aceste cereri Http vor fi direcționate fie către un server de origine, fie către un server de cache proxy, iar acel server va genera un răspuns Http. De obicei, orice set de solicitări / răspunsuri are:

  • Cerere – Faceți o cerere HTTP la o adresă URL
  • Răspuns – Solicitarea va returna un răspuns care poate fi o eroare sau un succes.
  • Date care pot fi analizate – În telefonul mobil trebuie să analizăm răspunsul la un obiect, date Class sau Struct pe care îl putem folosi în interiorul aplicației, folosind unele terțe părți, cum ar fi Moshi, Json, Gson *, puteți chiar să vă construiți propriile dvs., dar când ajunge la telefon, este un șir simplu.

De obicei, orice solicitare / răspuns Http are următoarele două lucruri:

  • Uniform Resource Locator: o adresă URL este o locație specifică, o adresă undeva pe internet cu un anumit tip de metodă
  • Head ers: Oferă clientului și serverul transmite informații suplimentare cu un HTTP cerere sau răspuns. Un antet HTTP constă din numele său care nu face sensibilitatea la majuscule și minuscule, urmat de două puncte (:), apoi de valoarea acestuia.
  • Corp: Răspunsul real, un șir simplu care expune conținutul corpului, nu poate fi nimic pentru o metodă, chiar și o unitate, de exemplu.

Pentru fiecare solicitare primim un răspuns, indiferent dacă nu are succes, avem un cod de stare pentru a-l cunoaște:

  • 1xx – Totul este grozav, așteaptă puțin
  • 2xx – Totul este în regulă, acesta este un răspuns pe deplin succesiv
  • 3xx —Răspunsul este în altă parte, sunteți pierdut
  • 4xx— Solicitarea de către client este slab îndeplinită, deci aceasta este o eroare din partea mobilului
  • 5xx – Serverul nu a reușit să îndeplinească o cerere corectă, deci aceasta este o eroare din partea backend

Metode HTTP

Există mai multe metode HTTP

  • @GET: Este utilizat pentru citirea sau preluarea informațiilor despre o resursă. Solicitările GET sunt utilizate numai pentru a citi datele și nu pentru a le modifica, sunt considerate sigure
  • @POST: Este utilizat pentru crearea de resurse noi. În special, este folosit pentru a crea resurse subordonate. Nu este nici sigur, nici idempotent. Prin urmare, este recomandat pentru solicitări de resurse neidentificate.Efectuarea a două solicitări POST identice va duce cel mai probabil la două resurse care conțin aceleași informații.
  • @PUT: Este utilizat pentru actualizarea capabilităților, PUT-o la un URI de resursă cunoscută cu corpul cererii care conține reprezentarea recent actualizată a resursei originale. PUT nu este o operațiune sigură, deoarece modifică (sau creează) starea de pe server, dar este idempotent. Cu alte cuvinte, dacă creați sau actualizați o resursă utilizând PUT și apoi efectuați același apel din nou, resursa este încă acolo și are în continuare aceeași stare ca la primul apel.
  • @DELETE: Este utilizat pentru a șterge o resursă identificată printr-o adresă URL.
  • @PATCH: Este utilizat pentru a modifica capacitățile. Solicitarea PATCH trebuie să conțină doar modificările resursei, nu resursa completă. PATCH nu este nici sigur, nici idempotent.

Oricum, orice modificare din oricare dintre aceste metode pentru o aplicație mobilă poate fi semnificativă periculoasă, permite imaginea unei aplicații care primește o variabilă ca dublă într-un răspuns. , dacă acest lucru se schimbă într-un fel într-un Boolean, analiza datelor va fi întreruptă, aceasta este o capcană uriașă pe care inginerii backend trebuie să o ia în considerare de fiecare dată când schimbă un punct final care este consultat la producție.

HttpClient

Astăzi, majoritatea aplicațiilor Android sunt construite pe API-uri. Un API este, în general, un serviciu web RESTful (poate fi o mulțime de lucruri, este doar un exemplu) care poate fi accesat prin HTTP și expune resurse care permit utilizatorului să interacționeze cu aplicația, de cele mai multe ori avem nevoie de un HttpClient pentru a face acces pe internet și începeți să preluați date pentru utilizatorii noștri.

În Android, avem o bibliotecă incredibilă care creează un HttpClient în câteva secunde, numit OkHttpClient , acest lucru va crea un client, cu readTimeOut și ConnectionTimeOut, dacă serverul nu oferă niciun răspuns în acest interval de timp, vom ajunge la o conexiune care nu are succes.
Există o parte foarte importantă a acest client, putem pune, de asemenea, un constructor pentru cache (și multe alte lucruri despre care vom vorbi mai târziu în acest serial)

Cache

Preluarea resurselor prin rețea este atât lentă, cât și costisitor, principalul motiv este că depindem de mai multe lucruri în mobil, de exemplu, de rețeaua în care se află utilizatorul nostru, de la 5G la 3G, de la WIFI cu fibră optică la cabluri de comunicații

Cache-ul este proiectat pentru a face apeluri de rețea mai bune pentru toată lumea, chiar și pentru utilizatori, deoarece acestea se vor termina fără solicitări de rețea inutile. Capturarea nu va înlocui niciodată un apel original către DNS-ul dvs., de exemplu, memoria cache nu va fi niciodată un substitut pentru preluarea datelor din sursa sa.

Cache-ul bazei de date
De fapt nu este vorba despre stratul de rețea, ne întrebăm API-urile despre informații și le stocăm în SharedPreferences, DataStore sau în orice bază de date care poate fi relațională sau nerelativă. Performanța, atât în ​​ceea ce privește viteza, cât și viteza de producție pe care o oferă baza de date poate fi cel mai impactant factor al performanței generale a aplicației dvs.

Rețeaua de livrare a conținutului
Când traficul serverului dvs. este la nivel mondial, nu este întotdeauna o metodă ușoară și costisitoare de a replica întreaga infrastructură de pe tot globul și, pentru aceasta, avem CDN care vă oferă posibilitatea de a utilizați rețeaua sa globală de locații marginale pentru a livra o copie cache a conținutului API-urilor dvs., inclusiv imagini, streaming și video

Sistem de nume de domeniu
Fiecare solicitare de domeniu efectuată pe internet interogă în esență serverele cache DNS pentru a rezolva adresa IP asociată cu numele domeniului. Memorarea în cache a DNS-ului poate apărea la mai multe niveluri, inclusiv pe sistemul de operare, prin intermediul ISP-urilor și serverelor DNS.

Pentru rețea în mod specific, putem face ca HttpClient să gestioneze Cache (verificați codul de mai sus) și Non-Cache, de exemplu în unele aplicații este posibil să avem o atracție pentru reîmprospătare, poate fi necesar să omiteți memoria cache și să preluați datele direct de pe server. Pentru a forța o reîmprospătare completă, adăugați no-cache direct în generatorul de cache pentru clientul dvs. OkHttpClient, decizia de a efectua acest tip de apeluri este mai ales în funcție de produs decât de punct de vedere tehnic.

Acest lucru este totul pentru această parte a postării . Pentru următoarea parte, vom discuta despre certificate, fixare și TSL!

Dacă aveți nevoie de ajutor:

Sunt întotdeauna bucuros să vă ajut, mă puteți găsi aici:
Mediu ca
Twitter ca @ddinorahtovar
StackOverflow ca Dinorah Tovar

Happy Coding! 👩🏻‍💻