In our latest BETA we introduced SiaqodbSyncMobile which allows you to work with your data even there is no connection available and synchronize later on when connection is available with a cloud database.

Why?

With Azure Mobile Services you can store data in the cloud using Windows Azure SQL database, blob storage, table storage or third party data services like MongoDB, but it requires a permanent and stable connection for your app. There are a lot of situations when connection for mobile devices is poor/unstable so it leads to poor user experience.
SiaqodbSyncMobile solves this problem by offering a fully offline working mode for your app; basically you can manipulate data without connection at all, by storing it on local Siaqodb database and, later on, when connection is stable, you may synchronize those changes with cloud database. Even more you can work in parallel offline/online, so if a Save to server fails, you can fall back and store that entity offline in Siaqodb database. It also brings costs benefits since your traffic with cloud will decrease.

The synchronization process it’s complex internally but very powerful, offering possibility and flexibility to detect and resolve conflicts if two or more clients write changes to same item. Azure Mobile Services offers Optimistic Concurrency Control but only for Update operation, it does not catch and handle Delete operations. With SiaqodbSyncMobile all conflicts may be detected and resolved as app needs; those conflicts are caught using server-side scripts where you can define your custom business logic.

How it works?

Supposing you have your entity defined as:

 public class TodoItem
    {
        [JsonProperty(PropertyName = "id")]
        public string Id { get; set; }

        [JsonProperty(PropertyName = "text")]
        public string Text { get; set; }

        [JsonProperty(PropertyName = "complete")]
        public bool Complete { get; set; }

        [JsonProperty(PropertyName = "__version")]
        public string Version { get; set; }
    }

Notice that besides business logic properties:Id,Text and Complete, there is also added Version property which is “system property”.

“__version” field is a TimeStamp which is updated every time a record is modified(on server). To be able to handle concurrency you’ll have to add this system property to your entities, but you don’t have to assign value to it or use it, it will be handled automatically by SiaqodbSyncMobile and on server side by Azure system.

You can now manipulate objects online/offline or mix them.
If your app is online you may work directly with Azure Mobile Services:

using Microsoft.WindowsAzure.MobileServices;
.....
 
   MobileServiceClient mobileService = new MobileServiceClient("https://yourAMS.azure-mobile.net/","yourAppKey");
   IMobileServiceTable<TodoItem> todoTable = mobileService.GetTable<TodoItem>();
   await todoTable.InsertAsync(new TodoItem(){Id=Guid.NewGuid().ToString()});

If your app is offline you can store the object on local Siaqodb database and later on Sync:

using Sqo;
using SiaqodbSyncMobile;
.....
    SiaqodbMobile localDatabase = new SiaqodbMobile("https://yourAMS.azure-mobile.net/","yourAppKey", "mylocaldb");
    await localDatabase.StoreObjectAsync(todoItem);

later on when connection is back:

//here all local changes will be uploaded to server and new changes(done by other clients) will be downloaded
    await localDatabase.SyncProvider.Synchronize();
 

That’s it, now your application works regardless connection.

How synchronization process works?

There are 2 big steps in the Sync process:
A.Upload changes to server
B.Download changes to server

A1.Inserts are packaged and uploaded to server in batch(so all inserted records are uploaded in one package/one request)
A2.Updates are packaged and uploaded to server in batch(so all updated records are uploaded in one package/one request)
A3.Deletes are packaged and uploaded to server one by one (Delete script does not allow batch upload since it gets only ID as argument and not the entity)

B.Download all entities at once(inserted, updated and deleted-yes even deleted, but only IDs and tableNames)
B1.Store inserted and updated items on local db.
B2.Apply deletes on local db.

This is the simplified flow of the Sync process.

How concurrency conflicts are handled and resolved?

Two or more clients may write changes/or delete the same item, at the same time. Without any conflict detection, the last action would overwrite any previous updates/delete which is not desired.
SiaqodbSyncMobile detects those conflicts and allows you to resolve them or it will resolve them automatically by our customization of server-side scripts. We offer a tool to generate those scripts and also instructions how to upload them all at once.

Let’s imagine a typical case where we have 2 clients(C1 and C1) and a record R1; in the following cases a conflict may occur:

1.C1 update R1, C2 update R1
2.C1 update R1, C2 delete R1
3.C1 delete R1, C2 update R1
4.C1 delete R1, C2 delete R1

When C1 and C2 synchronize those changes to server, it depends who will Sync first.
Let’s suppose C1 Sync first and no other clients updated/deleted R1, then all C1 changes will be applied with no conflict.
When C2 will try to Sync, based on __version column and tombstone table, server side scripts will detect a conflict and will handle as:
1.a.If conflictWinner=”server”-> means C2 update will be rejected since C1 update was applied already
b.If conflictWinner=”client”->means C2 updated will be applied over C1 update
c.You can customize who is “winner” based on your business needs.

2.a.If conflictWinner=”server”-> means C2 delete will be rejected since C1 update was applied already
b.If conflictWinner=”client”->means C2 delete will be applied over C1 update
c.You can customize who is “winner” based on your business needs.

3.a.If conflictWinner=”server”-> means C2 update will be rejected since C1 delete was applied already
b.If conflictWinner=”client”->means C2 update will be applied over C1 delete(so record will be reinserted into db with C2 changes)
c.You can customize who is “winner” based on your business needs.

4.a.If conflictWinner=”server”-> nothing happen since C1 delete was applied already
b.If conflictWinner=”client”->nothing happen since C1 delete was applied already
c.You can customize who is “winner” based on your business needs.

Inside Siaqodb4.0Beta package you will find also a tutorial how to start using Siaqodb and Azure Mobile Services and also full examples.

We wait for your feedback!