Praktisches Netzwerk für Android-Entwickler (Teil 1)

( 7. November 2020)

Einfache Datenschicht für jede Anwendung

Hier ist die Liste der Blogs in dieser Reihe:

  • ( Teil 1 – HTTP und Netzwerkschicht )
  • (Teil 2 – TLS, Zertifikate und Pinning)
  • (Teil 3 – Authentifikatoren und Interzeptoren)
  • (Teil 4 – Leistung, Redundanz und Parallelität)
  • (Teil 5 – Testen und Integration)
Praktisches Netzwerk für Android-Entwickler

Dies ist der erste Teil dieser Serie „Praktisches Netzwerk für Android-Entwickler“ wenn wir über die Netzwerkdatenschicht mit einer anderen Vision sprechen, die normalerweise adressiert ist d, weil das Networking auf Android schwierig zu funktionieren ist, mit mehreren Netzbetreibern, unterschiedlichen und umfangreichen Inhalten, Streaming und all dies sollte bei unseren Benutzern ankommen, ohne ein einziges Detail zu verpassen.

HTTP und Network Layer

HTTP ist ein Netzwerkprotokoll. Wenn Sie eine Verbindung zum Internet herstellen, das Sie verwenden, lautet die hübsche Version der Definition: HTTP lautet:

“Ein Anwendungsschicht Protokoll für verteiltes, kollaboratives hypermedia Informationssysteme ”

Dies bedeutet im Grunde genommen eine Reihe von Dingen, wenn Sie eine Website erstellen , Smartphone-App, IoT, auch nur ein Download einer Datei, Sie verwenden dieses Protokoll, es hat sich von Webseiten mit einfachem HTML über Webanwendungen zu mobilen Apps entwickelt und hat sich zu einer API-Schicht entwickelt, die häufig verwendet wird.

HTTP-Anforderungen ts werden von unseren Benutzern generiert, wenn der Benutzer mit unserer mobilen App interagiert. Wir fordern Informationen von einem Server an, wenn ein Klick ausgeführt wird, z. B. ein Bildlauf oder eine Löschung. Stellen Sie sich beispielsweise Google Mail vor, jedes Mal, wenn Sie in die App eine HTTP-Anfrage eingeben wird erstellt, damit die E-Mails aktualisiert werden. Wenn Sie eine E-Mail löschen, beantworten oder sogar öffnen, wird eine HTTP-Anforderung generiert. Diese HTTP-Anforderungen werden entweder an einen Ursprungsserver oder einen Proxy-Caching-Server gesendet, und dieser Server generiert eine HTTP-Antwort. Normalerweise hat jeder Satz von Anfragen / Antworten:

  • Anfrage – Stellen Sie eine HTTP-Anfrage an eine URL
  • Antwort – Die Anforderung gibt eine Antwort zurück, die ein Fehler oder Erfolg sein kann.
  • Daten, die analysiert werden können – In Mobilgeräten müssen wir die Antwort auf ein Objekt, Daten, analysieren Klasse oder Struktur, die wir in der App verwenden können, mit einigen Drittanbietern wie Moshi, Json, Gson * können Sie sogar Ihre eigene erstellen, aber wenn sie das Telefon erreicht, handelt es sich um eine einfache Zeichenfolge.

Normalerweise hat jede HTTP-Anforderung / Antwort die nächsten paar Dinge:

  • Uniform Resource Locator: Eine URL ist ein bestimmter Speicherort, eine Adresse irgendwo im Internet mit einer bestimmten Art von Methode
  • Kopf ers: Gibt den Client und den Server übergibt zusätzliche Informationen mit einem HTTP Anfrage oder Antwort. Ein HTTP-Header besteht aus seinem Namen ohne Berücksichtigung der Groß- und Kleinschreibung, gefolgt von einem Doppelpunkt (:) und seinem Wert.
  • Body: Die tatsächliche Antwort, eine einfache Zeichenfolge, die den Body-Inhalt verfügbar macht, kann für eine Methode nichts sein, selbst für eine Einheit.

Für jede Anfrage erhalten wir eine Antwort, egal ob sie nicht erfolgreich ist, wir haben einen Statuscode, um sie zu kennen:

  • 1xx – Alles ist cool, warten Sie einfach ein wenig
  • 2xx – Alles ist in Ordnung, dies ist eine Antwort, die vollständig aufeinander folgt.
  • 3xx – Die Antwort ist woanders, Sie sind verloren.
  • 4xx – Die Anfrage des Clients lautet schlecht erfüllt, daher ist dies ein Fehler von der mobilen Seite
  • 5xx – Der Server hat eine korrekte Anforderung nicht erfüllt, daher ist dies ein Fehler von der Backend-Seite

HTTP-Methoden

Es gibt mehrere HTTP-Methoden

  • @GET: Wird zum Lesen oder Abrufen von Informationen zu einer Ressource verwendet. GET-Anforderungen werden nur zum Lesen und nicht zum Ändern von Daten verwendet. Sie gelten als sicher.
  • @POST: Wird zum Erstellen neuer Ressourcen verwendet. Insbesondere wird es verwendet, um untergeordnete Ressourcen zu erstellen. Ist weder sicher noch idempotent. Es wird daher für nicht idempotente Ressourcenanforderungen empfohlen.Das Ausführen von zwei identischen POST-Anforderungen führt höchstwahrscheinlich zu zwei Ressourcen, die dieselben Informationen enthalten.
  • @PUT: Wird für Aktualisierungsfunktionen verwendet und auf einen bekannten Ressourcen-URI übertragen Der Anforderungshauptteil enthält die neu aktualisierte Darstellung der ursprünglichen Ressource. PUT ist keine sichere Operation, da es den Status auf dem Server ändert (oder erstellt), aber es ist idempotent. Mit anderen Worten, wenn Sie eine Ressource mit PUT erstellen oder aktualisieren und dann denselben Aufruf erneut ausführen, ist die Ressource immer noch vorhanden und hat immer noch den gleichen Status wie beim ersten Aufruf.
  • @DELETE: Wird zum Löschen einer durch eine URL identifizierten Ressource verwendet.
  • @PATCH: Wird zum Ändern von Funktionen verwendet. Die PATCH-Anforderung muss nur die Änderungen an der Ressource enthalten, nicht die gesamte Ressource. PATCH ist weder sicher noch idempotent.

Jede Änderung innerhalb einer dieser Methoden für eine mobile Anwendung kann erheblich gefährlich sein. Stellen Sie sich eine Anwendung vor, die eine Variable als Double in einer Antwort empfängt Wenn dies irgendwie in einen Booleschen Wert geändert wird, wird das Parsen der Daten unterbrochen. Dies ist eine große Gefahr, die Backend-Ingenieure jedes Mal berücksichtigen müssen, wenn sie einen Endpunkt ändern, der in der Produktion konsultiert wird.

HttpClient

Heutzutage basieren die meisten Android-Anwendungen auf APIs. Eine API ist im Allgemeinen ein RESTful-Webdienst (kann eine Menge Dinge sein, ist dies nur ein Beispiel), auf den über HTTP zugegriffen werden kann und der Ressourcen verfügbar macht, mit denen der Benutzer mit der Anwendung interagieren kann. Meistens benötigen wir einen HttpClient, um Zugriff zu erhalten ins Internet und beginnen, Daten für unsere Benutzer abzurufen.

In Android haben wir eine unglaubliche Bibliothek, die in wenigen Sekunden einen HttpClient mit dem Namen OkHttpClient erstellt Dadurch wird ein Client mit readTimeOut und ConnectionTimeOut erstellt. Wenn der Server in diesem Zeitraum keine Antwort liefert, ist die Verbindung nicht erfolgreich.
Es gibt einen wirklich wichtigen Teil von Auf diesem Client können wir auch einen Builder für den Cache (und viele andere Dinge, über die wir später in dieser Serie sprechen werden) einfügen.

Cache

Das Abrufen von Ressourcen über das Netzwerk ist langsam und langsam Der Hauptgrund dafür ist, dass wir im Mobilfunk von mehreren Dingen abhängig sind, z. B. von dem Netzwerk, in dem sich unser Benutzer befindet, von 5G bis 3G, von WIFI mit Glasfaser bis zu Kommunikationskabeln.

Cache wurde entwickelt um Netzwerkanrufe für alle zu verbessern, auch für die Benutzer, da diese ohne unnötige Netzwerkanforderungen enden. Das Abfangen ersetzt niemals einen ursprünglichen Aufruf Ihres DNS pro Instanz. Der Cache ist niemals ein Ersatz für das Abrufen von Daten aus seiner Quelle.

Datenbank-Caching
Geht es eigentlich nicht um die Netzwerkschicht, wir fragen unsere APIs nach den Informationen und speichern diese in SharedPreferences, DataStore oder einer Datenbank, die relational oder nicht relational sein kann. Die Leistung Ihrer Datenbank in Bezug auf Geschwindigkeit und Durchsatz kann den größten Einfluss auf die Gesamtleistung Ihrer Anwendung haben.

Content Delivery Network
Wenn Ihr Serververkehr weltweit ist, ist es nicht immer eine einfache und kostengünstige Methode, Ihre gesamte Infrastruktur weltweit zu replizieren. Dafür haben wir CDN, mit dem Sie dies tun können Nutzen Sie das globale Netzwerk von Edge-Standorten, um eine zwischengespeicherte Kopie Ihres API-Inhalts bereitzustellen, einschließlich Bilder, Streaming und Video.

Domain Name System
Bei jeder im Internet gestellten Domänenanforderung werden im Wesentlichen DNS-Cache-Server abgefragt, um die mit dem Domänennamen verknüpfte IP-Adresse aufzulösen. DNS-Caching kann auf vielen Ebenen auftreten, einschließlich auf dem Betriebssystem, über ISPs und DNS-Server.

Für das Netzwerk können wir beispielsweise festlegen, dass unser HttpClient Cache (siehe Code oben) und Nicht-Cache verarbeitet In einigen Anwendungen kann es erforderlich sein, den Cache zu überspringen und Daten direkt vom Server abzurufen. Um eine vollständige Aktualisierung zu erzwingen, fügen Sie die no-cache direkt in Ihrem Cache-Builder für Ihren OkHttpClient hinzu. Die Entscheidung für diese Art von Aufrufen ist eher produktbezogen als technisch.

Dies ist alles für diesen Teil des Beitrags . Im nächsten Teil werden wir uns mit Zertifikaten, Pinning und TSL befassen!

Wenn Sie Hilfe benötigen:

Ich helfe Ihnen gerne weiter, finden Sie mich hier:
Medium als
Twitter als @ddinorahtovar
StackOverflow als Dinorah Tovar

Viel Spaß beim Codieren! 👩🏻‍💻