Android 1.5 and Database Storage | December 7th, 2009
OK, so as many of you know, I’m in Canada. In Canada, we have some pretty nasty providers. Honestly, choosing between Bell, Telus or Rogers is like choosing which limb you want to saw off. So, because I can’t wait anymore, I’ve decided to start work on SQLite Storage on Android 1.5. This will hopefully emulate the HTML5 storage, but I haven’t really tried it out too much yet. However, I found some weirdness with the databases.
Databases in Android have to be stored in the /data/data/
Package pack = this.getClass().getPackage();
String appPackage = pack.getName();
path = "/data/data/" + appPackage + "/databases/";
This is particularly handy when dealing with Databases in General, since you may want to take your code and throw the thing in a JAR so that you can deploy numerous apps easily. Of course, making a JAR for Android Development is a simple, but completely undocumented process. I’ll post about that later.
But the fact that this feature will be necessary because of the maintenance of the 1.x Android tree is depressing. I really wish that tricks like Java Reflection, and multiple APIs for multiple versions weren’t required, but at least we managed to hack around the annoying fragmentation for the time being.
January 1st, 2010 at 11:01 am
This approach will result in appPackage being given the value of “com.phonegap” (the package which the Storage class is in). Which I don’t think is really what you want, as it would mean any application that wants to make use of droidStorage would need to be in the com.phonegap package since access to /data/data/$PACKAGE is restricted to applications in $PACKAGE (this would also mean that all phonegap apps would also be able to access the databases from any other phonegap apps).
If you try accessing droidStorage from an application in package other than “com.phonegap” you’ll get the following error:
E/Database(11458): sqlite3_open_v2(“/data/data/com.phonegap/databases/iyfsexperience.db”, &handle, 6, NULL) failed
After which the application will crash.
Perhaps it would be better if there was a mechanism for setting the path manually?
My interpretation of this could be wrong, as my knowledge of java reflection is fairly shallow but my testing (and the resultant errors/crashes) seems to bear it out.
Cheers,
Mike.
January 4th, 2010 at 2:52 pm
This is about inheritance and not about relection. In fact, this has nothing to do with reflection.
This pattern apppears a LOT in PhoneGap. However, it can only appear in the DroidGap class. If you have a class derived from the DroidGap class that’s in its own activity, $PACKAGE will not be com.phonegap and instead will be the package of the derived app.
However, I didn’t realize this at the time, and shoved this into Storage, and since we’re using a Storage class, and not a class that was derived from storage, storage will give com.phonegap. Because of this, I’ve had to seperate this up into multiple calls, which is not the best thing to do, and this may be refactored in the future.
So, to recap. If you have a class that inherits another class, and you call this in the base class, it will get the package name of the derived class, since the derived class can have a different package than the base class.
But yeah, thanks for finding the bug.