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.

SQLite

The Android framework uses a concept called Content Provider to allow applications to share and use data across the platform. Typically, this Content Provider is backed by a SQLite Database where the data is actually stored.

A few days ago I saw a presentation of SQLite, actually a Google TechTalk made by it's developer, Richard Hipp, on May 31, 2006. I really liked it, so I wrote down some important features of SQLite:

• it's very small and compact (the code footprint has less than 250KB)
• serverless (writes directly to the disk drive)
• the database is contained in a single disk file
• zero-configuration (there is no need of setup or administration)
• you can read/write the database file with fopen(), fread(), fwrite()
• transactions satisfy ACID (atomicity, consistency, isolation, durability)

There are also some unusual features of SQLite:

• tends to ignore the data types (you can type whatever you want in every column - inspired by scripting languages)
• type affinity
• Example: If the type of a column is integer and you want to put there a string, if the string looks like an integer, it will be automatically converted, and if not, it will be stored as a string.
• ability to talk to multiple databases simultaneously (you can join 2 tables from 2 databases)

I managed to create a simple application which adds a person's first name and last name in a database using Content Provider. The user can see the data in the database on the screen, delete or add items. It looked pretty simple at first, but it took a whole day to actually realize how everything worked. 

Next step for me concerning the development of the application is to try to store some pictures in the database (binary data) and to use the CRUD functions that are implemented by parallel thesis. Also I must describe the requirements for my project.

Thesis description

With the fast advancement in information technology, database management systems are becoming more and more advanced. If at the beginning system designers and architects thought that a central control is better for database management, nowadays distributed database has become a better choice.

The purpose of the project is to allow users to reliably store and synchronize data between their mobile device and the cloud. When there is not a network connection between the client and the cloud, the data is stored locally, and when the connection becomes available, the cloud database is updated.

The database will be replicated to improve reliability, availability and fault-tolerance. The communication between clients and the cloud will be made through REST API and C2DM protocol. Android SDK, Google App Engine and Big Table are the technologies which will be used to develop this application.

This is team project, so I am going to work on the Android side, and my colleague Ion Morozan is going to work on the Server side of the same project.

My work is going to follow these steps:

1. Analyze requirements for application working with database allowing to load parts of the data to device while minimizing network overhead. Focus only on the Android part of the system.
2. Study and describe basic principles of Android OS, focus on content providers and SQLite and discuss which one best suits for this use case.
3. The system must support offline work (when possible) and replication to cloud.
4. Design system architecture of system.
5. Implement solution.