KWPro.net

I spent a good part of my day attempting to figure out how to solve a specific problem in Android.  The problem I encountered was dealing with multiple tables in a single SQLite Database being used amongst an application with multiple activities. Actually, the specific problem was the recommendation to utilize the SQLiteOpenHelper class to manage database/table creation and upgrades. I started off by taking the sample code from the Notepad application on the Android website.  However, the database adapter class was specifically designed for one table while the application itself only had one main activity.

The first problem was that the database adapter class needed to be refactored to support multiple tables.  Turns out that the class itself really should be designed to manage a single database for the lifespan of an application. If you need a better solution for CRUD operations on multiple tables, the base class provided in the example is not at all suitable. So to accommodate for this problem, I extracted the CRUD operations away from this class, creating a generic class for handling some basic CRUD operations. Then for each table, I could inherit this base class and define the columns and table name.  The trick to this was supplying the SQLiteDatabase reference back to these classes.

Now, here's where my next problem occurred. I needed some method to supply this database reference between activities. Originally, what I was doing was instantiating the adapter class every time in each of my activities' onCreate() method calls. The reason why is that the SQLiteOpenHelper requires a Context object passed in to determine whether or not to run it's own internal onCreate() or upgrade methods. What I discovered was that for each activity I landed upon that called this method, my database tables would be re-created. Obviously, this was a BAD THING.

So I looked around on the net for many hours, trying to find an elegant solution.  The two solutions that came up were Android Services and Content Providers.  The thing was that neither honestly were suitable.  Services are meant to be long running background processes while Content Providers are used for sharing data between applications, not just activities. Both situations were overkill for what I'm doing (which is just simple writes, although I do perform a few network calls, but that's an entirely different story).

What I really needed was something like a static or persistent variable, kinda like a persistent/shared connection that I could utilize between activities. The key was the android.app.Application object.

The android.app.Application is something your Android application can inherit that can be used to provide universal access between activities (and probably services, etc. as well; but I haven't yet delved into that section yet). So what you can do inside the android.app.Application inherited class is setup your so-called global variables.  Then inside your activity you can make a call like this:

MyApplication app = (MyApplication)getApplicationContext();
app.myVariable;

MyApplication would inherit Application.  Inside the onCreate() method, you can instantiate your DbAdapter class and pass it the MyApplication context.  From there, the MyApplication class can then manage the lifecycle of the DbAdapter variable.

Hopefully, I'll have some example code up on github sometime in the future.  Once I stabilize some of my classes, I might open source some useful generic classes people can employ.