Mobile Anwendungsdatenverwaltung
Meine Frage umgibt einen einzigen Punkt - Datenverwaltung in der mobilen Anwendung . Ich habe eine mobile Anwendung erstellt, in der Daten vom Server kommen. Die Daten umfassen sowohl Text als auch Bilder. Im Folgenden sind die Schritte, die ich dafür mache:
Erster Start:
1. Serverdaten abrufen.
2. Speichern Sie die Serverdaten in der Sqlite-Datenbank.
3. Zeigen Sie die Sqlite-Daten an.Nächste Starts:
1. Zeige SQL-Daten.
2. Serverdaten im Hintergrund abrufen.
3. Lösche vorherige SQL-Daten.
4. Speichern Sie neue Serverdaten in der Sqlite-Datenbank.
5. Zeigen Sie SQLite-Daten an.
Ich habe einige Fragen zu diesen Schritten:
1. Ist das der richtige Ansatz? Anderenfalls könnten Daten jedes Mal vom Server angezeigt werden, aber die Daten würden nicht sofort auf dem Bildschirm angezeigt (abhängig von der Internetgeschwindigkeit).
2. Ich habe auch daran gedacht, die Sqlite -Daten mit den neuen Serverdaten zu vergleichen. Aber eine große Herausforderung. Die neuen Serverdaten können neue Datensätze oder gelöschte Datensätze enthalten. Außerdem konnte ich keinen geeigneten Ansatz finden, um jedes Datenbankfeld mit JSON data zu vergleichen.
Also Was ist der beste Ansatz, um lokale Sqlite -Daten mit neuen Serverdaten zu vergleichen?
3. Jedes Mal, wenn ich die Sqlite -Daten lösche und neue Daten einfüge und dann den Bildschirm aktualisiere (der ein UITableView hat), blinkt er für eine Sekunde, was offensichtlich ist. Wie vermeide ich dieses Problem, wenn die Schritte 3, 4, 5 befolgt werden?
4. Wie soll ich mit der Datenaktualisierung fortfahren, falls ich jedes Mal auf den Bildschirm zurückkomme oder wenn die Anwendung aktiv wird? Ich bin mir sehr wohl bewusst, dass NSOperationQueues oder GCD verwendet wird. Aber was, wenn ich verrückt bin und hin und her gehe, um immer wieder zu screenen. Es wird eine Anzahl von NSOperations in der Warteschlange geben.
4 Antworten
Es ist eine Herausforderung, Serverdaten zu synchronisieren, das habe ich schon einmal gemacht, und wenn Sie Zeit damit verbringen können, würde ich sagen, es ist die beste Lösung.
Sie können Erstellungs- und Änderungsdaten sowohl auf Server- als auch auf lokalen Objekten benötigen, um sie zu vergleichen. So können Sie entscheiden, welche Objekte hinzugefügt, aktualisiert und gelöscht werden sollen. Wenn der Server nur die zuletzt aktualisierten Objekte sendet, können Sie viel Datenverkehr speichern und die Leistung verbessern (gelöschte Objekte sind jedoch schwerer zu erkennen).
Wenn die Daten nur auf dem Server geändert werden, ist es einfacher, wenn die App die Daten auch ändern kann, wird es komplizierter (aber es scheint, dass es nicht Ihr Fall ist). Es hängt natürlich auch davon ab, wie komplex die Datenbank ist.
Wenn Sie keine Zeit investieren wollen, funktioniert das Abrufen aller Daten immer, auch wenn es nicht ideal ist! Anstatt die alten Daten anzuzeigen und zu blinken, können Sie den Benutzer lediglich dazu bringen, beim Eingeben 2-3 Sekunden zu warten, während Sie die neuen Daten erhalten. Oder Sie können die Daten nur abrufen, wenn Sie die App starten. Wenn Sie diesen View-Controller aufrufen, ist er bereits fertig.
Es ist ein komplexes Problem, mit dem jeder irgendwann konfrontiert wird, also bin ich gespannt, was andere Leute vorschlagen werden:)
Das ist eine gute Frage.
Ich persönlich denke, dass das Herunterladen von Daten, das lokale Speichern und späteres Synchronisieren ein gefährliches Szenario ist. Einfache Einführung von Bugs, Master & lt; - & gt; Slave-Probleme (welche Daten sollten Master sein, wenn mehrere Geräte verwendet würden usw.)
Ich denke, so etwas könnte ein Arbeitsansatz sein:
1. Ich würde versuchen, Möglichkeiten zu prüfen, die Daten vom Server bei Bedarf zu laden. Wenn ein Benutzer eine View hat, die Daten anzeigen soll, laden Sie diese spezifischen Daten mit der Erstellung dieser bestimmten View. Dies stellt sicher, dass die Daten immer synchron sind.
2. Die Notwendigkeit, Daten vom Server aus jeder Ansicht neu zu laden, kann durch einfaches Speichern der heruntergeladenen Daten als Objekte im Speicher (ohne SqlLite) behoben werden. Die Ansicht versucht, die benötigten Daten über den Cache-Manager zu laden, und sie wird aus dem Speicher bereitgestellt, sofern verfügbar. Wenn Sie nicht im Speicher sind, holen Sie einfach die Daten von Ihrem Server und fügen Sie sie Ihrem Speichercache hinzu.
Der Speichercache könnte ein selbst erstellter Datenmanager sein, der ein Dictionary gespeichert auf Ihrem AppDelegate oder ein globales "Singelton" umhüllt, um die Cache-Verwaltung / das Speichern und das Laden von Daten zu übernehmen.
3. Bei Lazy Loaded Daten und Speichercaches müssen Sie sicherstellen, dass alle Aktualisierungen (Änderungen, neue Datensätze, gelöschte Datensätze) Ihr Speicherdatenmodell aktualisieren und diese Änderungen auch an die Server so bald wie möglich. Je nach Datengröße usw. können Sie den Benutzer zum Warten zwingen oder direkt als Hintergrundprozess.
4. Um sicherzustellen, dass die Daten synchronisiert sind, sollten Sie sicherstellen, dass Sie die lokalen Speicherdatensätze im Cache regelmäßig ungültig machen (löschen) und dadurch Datenaktualisierungen vom Server erzwingen. Der beste Ansatz wäre wahrscheinlich, einen letzten aktualisierten Zeitstempel für jeden Datensatz im Speichercache zu haben. Der periodische Invalidator würde also nur "alte Datensätze" aus dem Speicher-Cache löschen (wiederum nicht vom Server).
Um Server vor unnötiger Datenlast zu schützen, sollten die Daten immer noch auf Anforderung geladen werden, wenn der Benutzer sie in einer Ansicht benötigt, und nicht als Teil von "Cache-Invalidierung".
5. Abhängig von der Datengröße müssen Sie möglicherweise auf "Cache-Invalidisierung" achten. Es könnte so einfach sein, wie wenn xx Datensätze gespeichert werden, beginnen Sie mit dem Löschen alter Objekte aus dem Speicher-Cache (nicht Server, nur lokal auf dem Gerät).
6. Wenn die Datensynchronisierung absolut kritisch ist, sollten Sie den Speichercache für einen Datensatz aktualisieren, bevor Sie dem Benutzer das Ändern von Daten erlauben. Z.B. Wenn Benutzer auf "Bearbeiten" oder Ähnliches tippen, greifen Sie die neuesten Daten vom Server für diesen Datensatz. Dies dient nur dazu, sicherzustellen, dass der Benutzer einen Datensatz nicht mit veralteten Daten aktualisiert und dadurch unbeabsichtigt irgendwelche Änderungen außer Kraft setzt, die auf dem entfernten Gerät oder auf einem anderen Gerät vorgenommen wurden.
-
Ich nehme es an. Ich glaube nicht, dass es einen "perfekten richtigen Weg" dafür gibt. Aber das wäre das, was ich versuchen würde.
Hoffe, dass dies mit einigen Ideen und Inspiration helfen wird.
Wie wäre es damit:
- Wenn Daten in SqlLite vorhanden sind, laden Sie sie in die "speicherinterne" Kopie und zeigen Sie sie an
- Im Hintergrund laden Sie neue Serverdaten
- löscht alte sqlite-Daten, wenn sie vorhanden sind (beachten Sie, dass die Kopie im Speicher verbleibt)
- Speichern Sie neue Serverdaten in sqlite
- Laden Sie neue sqlite-Daten in die "In-Memory" -Kopie und zeigen Sie sie an.
Wenn in Schritt 1 keine Daten gefunden wurden, zeigen Sie dem Benutzer während Schritt 2 einen "Lade" -Bildschirm an.
Ich nehme an, dass die Daten von SqlLite klein genug sind, damit eine Kopie im Speicher in Ihrer UITable-Ansicht angezeigt wird (in der UITable-Ansicht werden immer Daten aus dem Arbeitsspeicher angezeigt).
Es ist möglich, die Schritte 4 und 5 zu kombinieren, wenn die Daten klein genug sind, um zwei Kopien gleichzeitig im Speicher zu halten (Sie würden eine neue In-Memory-Kopie erstellen und mit der sichtbaren Kopie austauschen, wenn sie abgeschlossen ist) / p>
Hinweis: Ich spreche hier nicht über Fehlerbehandlung, aber ich würde vorschlagen, dass Sie die SQLite-Daten nicht löschen, bis Sie neue Daten haben, um sie zu ersetzen.
Dieser Ansatz macht es auch überflüssig festzustellen, ob dies der erste Start ist oder nicht. Die Logik bleibt immer die gleiche, was es ein wenig einfacher zu implementieren machen sollte.
Ich hoffe, das ist nützlich.
Sie können die gleichen Dinge effizienter durch MultiVersion Concurrency Control (MVCC) tun, die einen Zähler (eine Art sehr einfacher "Zeitstempel") für jeden Datensatz verwendet, der aktualisiert wird, wenn der Datensatz geändert wird Holen Sie sich die Daten, die nach dem letzten Synchronisierungsaufruf aktualisiert wurden und viele redundante Daten und Bandbreite reduzieren.
Quelle: MultiVersion Concurrency Control
Tags und Links uitableview sqlite ios mobile-application data-management