Die Frage

Wie kann ich große Gruppen von gefilterten, sortierten, paginierten Daten in einer Einzelseiten-App verwalten, die auch auf ressourcenbeschränkten Geräten (z. B. Mobilgeräten) funktionieren muss?

Genauer gesagt; Ich habe einen Datensatz von mehr als 1000 geocodierten Ortsinformationsobjekten, der zu denen in einem Kartenansichtsfenster gefiltert wird. Aufgrund von Speicherbeschränkungen auf Mobilgeräten kann ich den gesamten Datensatz nicht zwischenspeichern. Aufgrund der langsamen Netzwerkverbindungen auf Mobilgeräten möchte ich jedoch HTTP-Anforderungen minimieren.

Was ist die beste Strategie für die Kombination aus maximalem Caching und minimalen Netzwerkanforderungen?

Irgendein Kontext

Ich baue eine Kartensplit-Ansicht für einen potenziell großen (1000+) Datenbestand in Australien:

Fahranforderungen sind:

• Muss auf alten / langsamen mobilen / Tablet-Computern sowie auf modernen Desktops arbeiten.
• Muss in der rechten Liste durch gesamte Datenmenge blättern können.
• Muss in der Lage sein, die Liste zu filtern, indem Sie die Karte verschieben / zoomen.
• Muss die Sortierreihenfolge (nach Ort, Name, ID usw.) ändern können.

Was ich versucht habe

Ich habe ein paar Iterationen im Umgang mit den Daten in der App *:

Iteration 1 (Naiv)

• Laden Sie die gesamte Liste der Daten in den Speicher und rendern Sie sie alle gleichzeitig.

Die Probleme treten bei Speicherbeschränkungen für mobile Geräte auf, da jedes Element in der Liste potenziell eine große Menge von Daten enthält (im JSON-Format).

Es gibt noch weitere Überlegungen, das DOM zu überladen, wenn die gesamte Liste gleichzeitig geladen wird (die Renderzeit im Browser macht die App unbrauchbar).

Iteration 2 (Lazy Loading)

• Implementiere lazy-loaded infinite scroll (a-la Twitter / Facebook).

Wenn wir eine "Seite" gleichzeitig machen (wo eine Seite ~ 30 Elemente ist), lösen wir die anfängliche Speicheranforderung, aber nachdem wir so weit gescrollt haben, stoßen wir wieder auf die Grenzen von Mobilgeräten.

Es gibt jetzt auch eine Netzwerkanforderung auf dem Handy - GPRS / EDGE-Geschwindigkeiten sind in Australien leider immer noch üblich und wirklich scheiße.

Iteration 3 (Daten entladen)

• Entladen Sie alte Daten aus dem Speicher / DOM, um die Geschwindigkeit zu erhöhen

Alte DOM-Elemente können durch leere Platzhalter ersetzt werden (um das Scrollen zu ermöglichen), und die zugehörigen Elemente in der Liste können aus dem Speicher entfernt werden. Dies löst das Problem der DOM-Beschränkungen.

Wir haben jedoch jetzt unsere Netzwerklast verdoppelt, wenn der Benutzer die Liste zurückscrollt. Dh, Es gibt keine zwischengespeicherten Daten mehr.

Iteration 4 (Cache & amp; Lazy Entladen)

• Cache X Anzahl der alten Ergebnisse (wobei X durch die Speicherkapazität des Geräts bestimmt werden kann), Entladen auf FIFO-Basis.

So kann unser Cache nun warm bleiben, und das Zurückscrollen sollte eine sofortige Ladung ohne Netzwerkanforderungen sein.

Was aber, wenn der Benutzer die Filter / Sortierkriterien ändert? Ein einzelner Cache ist nicht mehr wirksam, da die Ergebnisse in der Liste möglicherweise erneut gefiltert und für die Anzeige neu sortiert werden müssen.

Da das Dataset lazy loaded ist, verfügt die App nicht über ein vollständiges Dataset, um den Filter ordnungsgemäß auszuführen und zu sortieren. Daher ist eine HTTP-Anforderung erforderlich.

Der schlimmste Fall ist, wenn ein Benutzer die Karte leicht schwenkt. 1-2 Gegenstände können von einer Seite fallen, während 2-3 auf der anderen Seite hinzugefügt werden können. Jetzt, anstatt die möglicherweise zwischengespeicherten Daten erneut zu verwenden, laden wir unnötigerweise eine Netzwerkanforderung neu.

Iteration 5 (Delta-Ergebnisse)

• Übergeben Sie eine Liste der bereits bekannten id s mit der Anfrage und erhalten Sie nur das Delta der Ergebnisse

Dies speichert Daten, die über die Leitung heruntergeladen werden. Dies kann jedoch dazu führen, dass große Datenmengen über die Verbindung gesendet werden, sodass die API das Delta ausführen kann.

Iteration 6 (bekannte Bereiche)

• Niemals Daten erneut anfordern, die in einen bekannten Bereich fallen

Bereiche können eine Untergruppe der sichtbaren Begrenzungsbox (denke räumliche Partitionierung) oder eine "Seite" von 30 Ergebnissen beim Scrollen usw. sein.

Dies löst das Problem von zu viel Netzwerkverkehr (sowohl nach oben als auch nach unten), aber ich befürchte, dass die zum Speichern bekannter Bereiche erforderlichen Metadaten auch Speichergrenzen auf einem mobilen Gerät erreichen können.

Iteration 7 (Funktion beeinträchtigen)

• Entfernen Sie die Anforderung, dass die gesamte Liste scrollbar sein muss.

Wenn wir diese Anforderung entfernen, können wir die angezeigten Ergebnisse auf ein Maximum von beispielsweise 50-100 beschränken und bei der Ausführung auf einem Gerät bei der Methode Iteration 1 (naiv) bleiben erkannt als eingeschränkt in Fähigkeiten.

Die Frage (wieder)

Wie kann ich große Gruppen von gefilterten, sortierten, paginierten Daten in einer Einzelseiten-App verwalten, die auch auf ressourcenbeschränkten Geräten (z. B. Mobilgeräten) funktionieren muss?

* Hinweis: Ich habe das Rendering der Daten auf der Karte bereits mithilfe einer Clustering-Technik basierend auf der aktuellen Zoomstufe herausgefunden, daher ist dies kein Problem