Datenbank synchronisieren

Hallo,
ich möchte eine Datenbank via Dropbox API synchronisieren. Im Prinzip steht der Code schon und die Logik funktioniert (im Groben und Ganzen).

Eine Fragestellung ergibt sich aktuell noch für mich:
Wenn ich die Datenbank direkt synchronisieren möchte, also ich bemerkt habe, dass die DB online "neuer" ist, als die auf dem Handy, möchte ich sie herunterladen und dem Nutzer zur Verfügung stellen. Wenn ich nun direkt in die bestehende Datenbank schreibe (sprich unter "/data/data/xxx.xxx.meineapp/databases/meinedb.db") gibts das Problem, dass ein Nullptr auftritt. Kommt daher, dass die DB eigentlich noch in der App gebraucht wird (besser "offen ist") während die neue DB geladen und eingefügt werden soll.

Mein Plan ist aktuell folgender:
1. bestehende DB weiter offen lassen
2. neue DB in gleiches Verzeichnis herunterladen
3. wenn Download fertig, aktuelle DB aushängen (schließen) und Inhalt transferieren
4. DB wieder einhängen (öffnen)

Vermutlich wird das funktionieren, aber so 100%tig gefällt mir die Lösung nicht, da es ja trotzdem einmal einen (kurzen) "Cut" gibt. Hat jemand eine Idee wie man die Datenerneuerung möglichst sauber hinbekommt? Wäre es sinnvoll die Änderung vorzumerken und erst beim Aufruf von onPause die Daten zu tauschen (praktisch beim Activity-Wechsel)?

Danke vorab.

Ich würde den User informieren, das neue Daten da sind. Dabei würde ich fragen,
ob er sofort das update machen möchte
(dann kannst du seinen Workflow unterbrechen, closen, updaten und wieder open).
Wenn nicht, würde ich das dann beim Beenden der App in einem Service abarbeiten lassen.
Oder zu einem definiertem Zeitpunkt (evtl. vom User einstellbar, z.b. nur bei Wlan und nach 23:00 Uhr)
Das mit dem runterladen in eine 2te DB find ich nicht schlecht, man hat dann die Daten da und kann
schneller die Daten transferieren, denk ich mal.

So in der Art. Kein Ahnung ob du was damit anfangen kannst, wenn nicht, einfach schnell wieder vergessen

Ich denke auch gerade über eine Synchronisierung meiner App-Daten über irgendeine Cloud-Technologie nach.

Was mir immer wieder Kopfzerbrechen bereitet sind Konflikte. Also lokale Änderungen und remote Änderungen. Mit der Variante die komplette DB zu kopieren geht also immer eins von beiden verloren, richtig?
Ich würde es eher datenbasiert mergen. Also bei jedem Datensatz das Änderungsdatum (+ evlt. Änderungsdevice) mitspeichern und darüber dann die Daten zusammenfügen. Da kann es natürlich immer noch Konflikte geben, aber immerhin funktioniert es bei Änderungen an verschiedenen Datensätzen.

Das würde auch das Datenbank Problem lösen, da die Daten in die bestehende Datenbank eingefügt werden und nicht die komplette DB getauscht wird.

deine Idee ist ganz gut, deek. Per Datum lässt sich noch am ehesten eine halbwegs "sichere" Mergelogik realisieren.
Ich hab lange eine Anwendung programmiert, wo es eine Client/Server-geschichte für's Büro gibt mit
Datenabgleich für die Produktions-DB, das war noch recht easy.
Als dann die Außendienstler mit Laptop's rumliefen fing der Spass mit dem synchen erst richtig an
Dann merkt man recht schnell, das per Datum auch nicht gerade optimal bzw. sehr sicher ist, da
viele Geräte oft auch viele unterschiedliche Zeiteinstellungen bedeuten (das eine geht nur ein paar
sekunden falsch, das andere evtl. gleich mehrere Stunden).
Achso, eins fällt mir noch ein: wegen geschwindigkeit und so, kann es durchaus von Vorteil sein,
die DB vom mobilen Gerät auf den Server zu senden und dort das mergen zu machen (geht meist deutlich schneller).
Kommt aber natürlich auch auf die Größe der DB an.

Natürlich ist da auch viel von der Art deiner Daten abhängig, ich denke mal,
eine "universalregel" wirds da nicht geben.

Jo, genauso ist es, über die komplette Datei zu syncen hat eine verhältnismäßig große "mögliche Verlustrate". Wobei das eigentlich nicht mal sooo das Problem sein sollte (eine Anwendung ist am PC und die andere auf dem Handy), dass beide Geräte Änderungen erhalten und beide keinen Zugang zum Internet haben (und das noch über die Dauer der kompletten Zeit der Nutzung) ist zwar möglich, dürfte in meinem Fall eher selten sein. Aber genau hier entsteht schon ein relativ großes Problem: wenn "ständig" synchronisiert werden könnte, wird der Rattenschwanz mit Problemen bezgl des Ein- und aushängen immer länger.
Die Dropbox bietet für das mergen auch ein passendes Modell an, sofern ich das richtig gesehen habe (hab den Part aber nur überflogen, schaue ich mir später nochmal an und berichte, wenn ich mehr weiß).
Danke euch schon mal für den Input, das mit dem Datum ist auch ein Ansatz von mir gewesen und das Problem mit den verstellen Uhren hatte ich jetzt in den ersten Testläufen auch noch nicht auf dem Radar.
Denke dass nun der Plan doch in Richtung mergen geht, vermutlich ist so der komplette Code bzw die Abfolge wirklich besser strukturiert, nachvollziehbarer und ggf auch einfacher zu prüfen/testen.

Häufig macht das Arbeiten mit Brechstange mehr Arbeit, als gleich das Skalpell zu nutzen. Trotzdem ist bei mir komischerweise IMMER erstmal die Brechstange am Start.

Die verstellten Uhren kann man heutzutage imho vernachlässigen. Es synchronisiert sich ja alles übers Netz. (man sollte aber Zeitzonen-agnostisch speichern)

@zumafx: Ja Synch ist immer so eine Sache, kenne ich. Da der "Server" in diesem Fall die Dropbox ist, wird das mit extern mergen aber eher nichts

Hallo,

manchmal ergeben sich Anregungen aus anderen Lösungen:

"Synchronization Example"
https://msdn.microsoft.com/en-us/sync/bb821992.aspx