ORMLite

After finishing creating everything with generic classes, I was trying to upgrade my design, so that the developer could create multiple tables and relations between them. While documenting, I walked into ORMLite. This is the ORM for SQLite. I found it so easy to use and developer friendly, that I thought of giving it a try.

You can add it very easily to your project - just download the 2 needed jars from ormlite.com (ormlite-core.jar and ormlite-android.jar - version 4.39 at the time of this post) and everything will work like a charm. What you need to do is Annotate your Classes using ORMLite Annotations or javax.persistence Annotations. The next step is to configure a DAO, but for more examples and information use this link.

What got me thinking about ORMLite is the size of it - approximately 250KB. Since I don't really need all the options that ORMLite offers, I started working on my own ORM (very simple one). I created some custom Annotations for my classes, but what I am working now on is dealing with Content Provider, which is mostly used with databases with single tables, and even if you have multiple tables, the most common way to distinguish between them is through URIs. I cannot do this, because I only have the name and number of the tables at run-time, when the Content Provider has already been initialized.

Currently I can create the query for creating a new table, but I don't get the chance to use it. I will write in the future about the solution I found. I hope I will find something better than rawQuery.

The steps I want to follow in the near future are:

• Update the Content Provider so that it can work with multiple tables 
• create tables at run-time
• update the needed URIs used in Content Provider
• Use C2DM to update the SQLite database. Currently I am only receiving "Hello world" messages from the server. 

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.