+ Antworten
Ergebnis 1 bis 6 von 6

Thema: Restservice(s) Best Practice

  1. #1
    User Kilobyte Themenstarter

    Registriert seit
    28.08.2013
    Fachbeiträge
    152
    Genannt
    7 Post(s)
    Hallo Community,

    ich brauche eure Erfahrung in Bereich Restservice und mobile Apps. Ihr kennt doch diese Auswahlfelder, wo zuerst das erste Dropdown Feld gefüllt ist und wenn dort was ausgewählt wird, wird das nächste gefüllt. Ich habe 4 von solchen Dropdownfeldern (Kontinent => Land => Ort => Lagerplatz). Diese Informationen sind nicht fix und müssen dynamisch über Restservices geladen werden.

    Nun ist die Frage, ob ich alle Daten beim ersten mal lade, oder 4 Requests durchführe. Bei einem großen Request können im schlimmsten Falle 50-100Kb geladen werden. Bei 4 kleinen Request sind es vielleicht 4x2Kb. Rein von der Datenmenge wäre die Entscheidung klar. Aber was ist, wenn das Smartphone eine schlechte Internetverbindung hat. Können die kleinen Request zwischen den Auswahlfeldern dann so langsam werden, dass die Userexperience deutlich gestört ist? Was sind da eure Erfahrungen bei Restservices und langsamen Internetverbindungen?

  2. #2
    User Kilobyte
    Registriert seit
    13.10.2015
    Fachbeiträge
    165
    Genannt
    19 Post(s)
    Es kommt darauf an.

    Der Vorteil bei einem grossen Request ist, wenn ich den Fall korrekt sehe, dass dieser nur ein einziges Mal gemacht werden muss.
    D.h. der Client könnte unter Umständen auch das Ergebnis cachen, wenn der Request immer das gleiche zurück gibt.
    Ist ja meist so, dass man nicht nur einmal etwas einlagert, sondern evtl. mehrere Sachen hintereinander.

    Hier kann man z.B. mit den E-Tags arbeiten.

    Die Anfrage an den Server, wäre also einmalig alle Daten holen und dann nur noch die Abfrage, ob sich das Ergebnis geändert hat, also ein weiterer Lagerplatz hinzugekommen ist.
    Bleibt alles gleich, dann kommen da auch kaum zusätzliche Daten zusammen. HTTP Status 304

    Ändert sich hier regelmässig etwas, oder ist die Antwort Kontextabhängig, dann kommen damit schon mehr Daten zusammen.


    Ein weiteres entscheidendes Kriterium ist die Zeit, die ein Request benötigt um überhaupt, den Weg zum Server zu finden und die Antwort zum Client zu transportieren. Das kann die UX schon ganz schön stören.


    Aber um es ganz genau herauszufinden, wäre wohl ein Experiment das Beste, wohl auch nicht allzu aufwendig . Dann gibt es eine empirische Antwort, die auch auf den Fall passt.

    https://de.wikipedia.org/wiki/HTTP_ETag

  3. #3
    Global Moderator Viertel Gigabyte Avatar von SlaterB
    Registriert seit
    06.08.2008
    Fachbeiträge
    2.695
    Genannt
    275 Post(s)
    allgemein genannt:
    Hintergrund-Laden, und bei gleichmäßig mehrstufigen Verzweigungen
    10 - 100 - 1000 - 10.000
    könnte man etwas überlappend laden, für das Beispiel hier genannt:

    am Anfang braucht es ja eh die ersten 10 Einträge, 10 Kontinente (Anzahlen nur Beispiel),
    da könnte man dann auch gleich neben den 10 Kontinenten die insgesamt 100 möglichen Länder am Anfang parat haben, Datenmenge hält sich in Grenzen

    wird ein Kontinent ausgewählt, dann sind die 10 Länder für die zweite Wahl sofort vorhanden,
    intern könnte schon die 100 Orte des Kontinents, der 10 Länder, geladen werden,

    ist ein Land ausgewählt dann 10 Orte des Landes sofort verfügbar usw.,

    ist nicht so effizient wie jeweils nur die 10 benötigten Elemente zu laden, dafür aber auch nicht unbedingt zu warten,
    je nachdem wie schnell der Bediener vs. Nachladen ist,
    das Laden von Zehntausenden Daten dennoch vermieden, ein Mittelweg

    -----------

    bei deinem Beispiel dürften Kontinente und Länder problemlos direkt am Anfang als Daten vorhanden sein,
    mit Programm geladen oder was immer als Updates geplant,
    falls keine Updates und Länder auf Server später hinzukommen, ok, dann vielleicht nicht so leicht machbar..

    bei Auswahl eines von nur 6 Kontinenten sämtliche Orte des Kontinents nachzuladen, das erscheint hier nicht ganz verhältnismäßig,
    dann lieber doch Land auswählen lassen und an dieser Stelle eine kleine Wartezeit riskieren

    wieviele 'Lagerplätze' gibt es pro Ort? falls nur einstellige Zahl im Mittel, dann könnten die beim Laden der Orte gleich dazukommen,
    oder auch bei vielen Lagerplätzen wenn dazu entschlossen,

    so insgesamt nur einmal Nachladen vielleicht akzeptabel
    Hansa wird Meister

  4. #4
    User Viertel Megabyte Avatar von TMII
    Registriert seit
    19.02.2015
    Fachbeiträge
    313
    Genannt
    31 Post(s)
    Ich argumentiere im Akku-Verbrauch dass die 50-100kb besser sind. Smartphones schalten den Netzbetrieb auf Standby um Akkuleistung zu sparen, viele einzelne Requests halten die Netzverbindung unnötig lange aktiv.

    Diese kleinen Antennen im Smartphone müssen das Signal immerhin mehrere Kilometer weit transportieren.

    Deshalb lieber einzelne Große statt viele Kleine.

    *** Edit ***

    https://developer.android.com/traini...ork/index.html

    Können die Daten nicht auf dem Smartphone gecached werden und stattdessen erstmal auf Gültigkeit validiert werden.

  5. #5
    User Kilobyte
    Registriert seit
    13.10.2015
    Fachbeiträge
    165
    Genannt
    19 Post(s)
    Zitat Zitat von TMII Beitrag anzeigen
    Können die Daten nicht auf dem Smartphone gecached werden und stattdessen erstmal auf Gültigkeit validiert werden.
    Sorry, wenn ich nochmal Frage, aber habe den Satz nicht ganz verstanden, da etwas zweideutig.

    • Caching funktioniert nicht unter android
    vs
    • Versuche es doch mal mit caching

    Zumal es noch auf die jeweilige Technologie ankommen kann. Mit einem Standard-Browser stehen andere Möglichkeiten offen, als mit einer App.
    Zudem kann man bei einer App auch noch andere libs nutzen, die einem einen teils erweiterten Funktionsumfang bieten oder zumindest einfachere Nutzbarkeit.


    Off topic:
    Apropos Akkuverbrauch, habe letztens noch von einer Studie gehört, bei der Collections bezgl. der Energieeffizienz untersucht wurden.

  6. #6
    User Kilobyte Themenstarter

    Registriert seit
    28.08.2013
    Fachbeiträge
    152
    Genannt
    7 Post(s)
    Sehr interessant, was hier noch für Ideen kommen. Auf das Vorladen von 2 Dropdown Feldern wäre ich nie gekommen
    Auch das mit dem Cache ist noch interessant, sodass man nur fragen muss, ob die Daten noch passen. Die werden sich selten ändern. Den ETag kannte ich noch nicht.

    Den Akkuverbrauch hatte ich auch schon im Kopf, aber zuerst UX, dann Akku.

    Danke

+ Antworten Thema als "gelöst" markieren

Direkt antworten Direkt antworten

Schreibe die Ziffern der folgenden Zahl! Sechsundzwanzigtausenddreihundertsiebenundvierzig

Aktive Benutzer

Aktive Benutzer

Aktive Benutzer in diesem Thema: 1 (Registrierte Benutzer: 0, Gäste: 1)

Ähnliche Themen

  1. (Best Practice)>/i>
    Von EikeB im Forum Kritiken & Anregungen
    Antworten: 10
    Letzter Beitrag: 27.08.2013, 14:00
  2. Best Practice: HTML Layout
    Von Swoop im Forum HTML / CSS / JavaScript / AJAX
    Antworten: 13
    Letzter Beitrag: 16.08.2013, 09:20
  3. Best Practice: obj.get() vs get(obj)
    Von Natac im Forum Allgemeine Themen
    Antworten: 31
    Letzter Beitrag: 06.08.2013, 13:29
  4. best practice to use a CUDA class?
    Von seinecle im Forum JCuda
    Antworten: 3
    Letzter Beitrag: 09.03.2012, 19:04

Berechtigungen

  • Neue Themen erstellen: Ja
  • Themen beantworten: Ja
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •