I'm writing a simple "todo - helloworld" with jqueryMobile + knockout + breeze + WebAPI to learn about SPAs (Single Page Application) in a mobile context (unreliable internet connection)
To enable offline usage the WebApp will leverage
The App should use whenever possible remote database for loading and saving data, but should be able to seamlessly switch to localstorage when offline and synchronize local/remote changes when back online.
Now back to the question: the App will use Breeze's EntityManager for managing data (local cache and remote sync)
To mitigate inconsistency/concurrency problems I would use 2 localstorage Keys:
so the flow would more or less be (pseudocode):
LoadData
if(online)
load remoteDb
save localDb // save a local copy of the fresh loaded remotDb
if(localPendingChanges)
load localPendingChanges // we are merging in the Breeze entityManager remote data with localPendingChanges
Savedata // we are online and we have pending changes, so we should sync everything back to the remoteDb as soon as possible
if(offline)
load localDb
if(localPendingChanges)
load localPendingChanges // we are merging in the Breeze entityManager local data with localPendingChanges
SaveData
if(online)
save remoteDb
clear localPendingChanges // until we are online there is no need to keep localPendingChanges
LoadData // we are loading data from remoteDb to update our localDb to the latest version
if(offline)
save localPendingChanges // we are saving only the changes to localstorage
What do you think about this approach? Is it a mess? Is it ok? What about concurrency problems in a multi user scenario?
This seems reasonable, not quite sure why you want two localStorage keys. The entityState (unmodified, modified, added, deleted) of every entity placed in localStorage is maintained so you can always 'extract' (see the EntityManager.getEntities method) just the pending changes from any local copy. So why not just save the entire entityManager state to localStorage before you shut down the app.
As for concurrency issues, you should definitely set a concurrency property on each entityType. As long as this exists, and if you are saving via the Entity Framework, breeze will detect any optimistic concurrency violations during a save and throw an exception. Obviously, you have determine the right behavior for your app after such an exception.
I'm sure you've seen it, but the QueryOptions.MergeStrategy (PreserveChanges, OverwriteChanges) can be very helpful in keeping or overwriting data on the local machine after any query.
I think you are correct on keeping local changes in a separate place from ones that are Sync'd with the Server. I have been tackling this problem for a few months and have come up with something that looks very much like a Version Control System where all data in a key within a set and everything is versioned separately. You can download changes from the Server into the Local database and it will handle if they have been changed on both sides through a conflict resolution callback.
At the moment I do not know much about Knockout, but the library itself is not dependant on any separate projects and is passing test cases in Node.JS, Dojo and jQuery. It has a super tight API (.get, .set, .feed (for loading downloaded data from the server) and .getFirst (for getting access to what needs to be uploaded).
The URL is at https://github.com/forbesmyester/SyncIt, it has a fairly comprehensive demo and docs too.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With