Click here to see my blog post on this subject.

Here is some sample code that illustrates three possible approaches. These will allow access to the database throughout the application.

Approach #1: have `SQLiteOpenHelper` be a static data member

This isn't the complete implementation, but it should give you a good idea on how to go about designing the DatabaseHelper class correctly. The static factory method ensures that there exists only one DatabaseHelper instance at any time.

/** * create custom DatabaseHelper class that extends SQLiteOpenHelper */public class DatabaseHelper extends SQLiteOpenHelper {     private static DatabaseHelper mInstance = null;    private static final String DATABASE_NAME = "databaseName";    private static final String DATABASE_TABLE = "tableName";    private static final int DATABASE_VERSION = 1;    private Context mCxt;    public static DatabaseHelper getInstance(Context ctx) {        /**          * use the application context as suggested by CommonsWare.         * this will ensure that you dont accidentally leak an Activitys         * context (see this article for more information:          * http://android-developers.blogspot.nl/2009/01/avoiding-memory-leaks.html)         */        if (mInstance == null) {            mInstance = new DatabaseHelper(ctx.getApplicationContext());        }        return mInstance;    }    /**     * constructor should be private to prevent direct instantiation.     * make call to static factory method "getInstance()" instead.     */    private DatabaseHelper(Context ctx) {        super(context, DATABASE_NAME, null, DATABASE_VERSION);        this.mCtx = ctx;    }}

Approach #2: abstract the SQLite database with a `ContentProvider`

This is the approach I would suggest. For one, the new CursorLoader class requires ContentProviders, so if you want an Activity or Fragment to implement LoaderManager.LoaderCallbacks<Cursor> with a CursorLoader (which I suggest you take advantage of, it is magical!), you'll need to implement a ContentProvider for your application. Further, you don't need to worry about making a Singleton database helper with ContentProviders. Simply call getContentResolver() from the Activity and the system will take care of everything for you (in other words, there is no need for designing a Singleton pattern to prevent multiple instances from being created).

Hope this helps!

I never read about using a singleton to access a db on android. Would you mind to provide a link about that.

In my apps, I use simple dbhelper objects, not singletons, I was thinking this is more the job of the sql engine to ensure db is not locked, not the job of your android classes, and it works pretty well for my biggest app that is medium sized.

Update #1: looking at the reference you gave, it looks like the problem is not at all about using different instances of a dbhelper. Even a single instance could encounter problems accessing the databases : the problem comes from a concurrent accesses. So the only way to ensure a proper access to the database by different threads is to use simple thread synchronization mechanisms (synchronized methods or blocks), and it almost nothing to do with using a singleton.

Update #2 : the second link you provide clearly shows that their is a need for singleton dbhelper objects in the case of multiple threads writing concurrently in a db. This can happen if you do you sql operations (inserts/updates/deletes) from AsyncTasks for instance. In that case a singleton object dbhelper would simply put all sql operations in some sort of pipeline and execute them in order.

This solution could be easier to implement than using proper thread synchronization using synchronized methods in java. Actually I think there should be more emphasize somewhere in android docs about this problem and the use of a singleton db helper could be encouraged.

Thanks for this nice question and the follow ups.