In my development of mobile apps, I have come across several cases that could benefit from a server-side backup-restore process as follows:

1. Installation of a new mobile client and connecting using an existing client account.
2. General information backup to protect information loss.
3. Periodic or on-demand publishing of client approved information to the “cloud” for information sharing.  An example is advertisement services that base their marketing efforts on user attributes, e.g., user profile definition or actual user usage statistics.

NOTE:  #3 is beyond the scope of this discussion and is left to the reader to adapt and enhance this more general server-side backup-restore process.

Some quick examples of these are the following.

1. New mobile client installation, a.k.a., I bought a new smartphone and I want to install the same apps I had on my previous smartphone, but require that all of my information be imported (retrievable) as well.
2. General information backup/restore, a.k.a., my information is important to me, thus I require a way to backup/restore my information.
3. Publishing of client approved information to the “cloud”. This is beyond the scope of our discussion, but this use case illustrates a potential feature that could benefit from the actual information transfer involved in this process.

Overview

I’m writing this post since I recently required a server-side backup-restore process for a mobile application I’m developing, and I’m betting many others can benefit from this discussion, including the example client and server-side code.  Android is my target mobile platform and ASP.NET MVC, using RESTful services is my server-side platform of choice.

Design

For this exercise, I will create a file of json serialized records at the client.  Each record represents one business entity, e.g., address record, contact record, note record, etc…

A RESTful service accepts the file, the version of the user records, and the user’s Id, and stores the file on the server appropriately named to associate it to the user.

NOTE:  Another option for storing records on the server, is to store them as key-value pairs, suitable for storage into a document repository such as mongodb.

Client Side:  The UserRecords Entity

The UserRecords is a self-contained entity that actually does most of the work for us.  It is a full-fledged business object and DTO.  We will start with the basics, and develop more as we go along.  Our primary properties are as follows:

public class UserRecords {
    public long UserId = -1;
    public byte[] UserRecords = null;
    public String RecordVersion = "1.0";

    public UserRecords() {
    }
}

More coming soon!