Future requirements - API

I was preoccupied by the graphics of the application, although this was not the main idea behind this project. I should focus more on creating the needed API, than some fancy application. The developer using my API should be able to create, read, update and delete some data from the SQLite Database, and the backup to Google App Engine will be made transparently by the API.

So I created a new application, which simulates the creation of a developer and uses it to back everything up to Google App Engine. I use Generic Classes, so no matter what fields the developer's class will have, everything will work just fine. I do this by creating a JSON file with the fields of the class:

private <T> String createJsonFile(Class<T> Kind) {
    String json;

    /*Get all fields, including the private ones*/
    Field[] fields = Kind.getDeclaredFields();
    int fieldsNo = fields.length;

    /*For each field, add to the JSON String the field's name*/
    for (Field field : fields) {
        fieldsNo--;
        json += "\"" + field.getName() + "\"";
        if (fieldsNo != 0)
            json += ",";
    }
    return json;
}

So these are the steps that I should follow while redesigning the application:

• Create JSON file from Class.
• Create SQLite Database with this structure (the table should have the same fields).
• Update the server concerning the schema.
• POST the JSON file
• Add one item to SQLite Database.
• Read/Modify/Delete items from SQLite Database.
• Synchronize the server when needed. 

These are small steps which I began already to implement. The last step can be further divided into smaller steps, but this is what I plan for now. It shouldn't be to difficult to implement, considering that most of it I already have, but I need to reorganize things.

An image with how should all look like is this one:

Requirements and restrictions

I made a list with the functional requirements of this project. Basically, this is what the system must do at the end:

• The application is going to use the Internet connection, so the client should have one.
• The client should have SQLite (it is already installed on every Android).
• Database must be: scalable, replicable and accessible from cloud.
• The user will be able to create/read/update/delete the data from the SQLite database.
• The communication between the client and the server will be made through REST architecture.
• The server will push information through C2DM, letting the client know that something has changed in the database. When receiving the message, the client will read the database from the server and modify his own accordingly.
• The client will store only a part of the database which exists on the server (the most probable to be used data).
• The system should make a difference between different connections
• For example – when using GPRS the system should use cache and when using WiFi the system should not cache the data.
• The user should be able to force relations between tables in the database.
• The structure sent between the client and the server will be in JSON format.
• The best way would probably be to use the GSON library to convert Java Objects in their JSON representation.
• The client should support offline work.
• When there is not an available Internet connection, the modifications will only be visible in the local database. When an Internet connection becomes available, the client should work with replication (send over the connection the modified data).
• For solving the replication we chose the simplest approach, the client which last modified the data (the most recent timestamp) is the winner.

There are a number of restrictions that I will enforce at the beginning, so that I can cover the most simple application. When the most simple case is working, I will remove one restriction and go for a more complicated solution.

1. The database stored in the cloud for one client fits entirely in the device memory.
2. The cloud database can only be accessed by Android, so no other Operating System.
3. There will not be 2 clients trying to modify the data at the same time - every time a client modifies something, the devices have time to synchronize.
4. There will always be available an Internet connection.
5. When a client modifies something in the local database, the whole database is copied on the server, so I will not use Delta updates.