I have a bit of workaround to solve this. Although you will probably
realize that this really doesn't seem like the final solution.
Anyway, as a linux/unix variant, Android supports symbolic (or soft)
links. Symbolic links allow you to tell the OS that a file is one
directory when it is really in another.
I had the same problem with a huge pre-built database (38MB).
SqlOpenHelper wants to find its databases in /data/data/<project
package name>/databases, so I created a symbolic link with the same
name as my database there and pointed it to the real file in a
directory on the sdcard.
For instance, if I had a db called "mydb.sqlite" which is stored in
the "/sdcard/myproj" directory which I want my Android app called
"org.example.koolapp" to use, I would execute the following at the
terminal/command prompt on my dev machine.
adb shell ln -s /sdcard/myproj/mydb.sqlite /data/data/
org.example.koolapp/databases/mydb.sqlite
A symbolic link is much smaller than the db and the SqlOpenHelper will
now be able to find the db!
Jack C. Holt
Science Applications International Corporation
twitter: hackeyflack
On Oct 21, 1:29 pm, Mark Murphy <[email protected]> wrote:
> Markus wrote:
> > I want to create a database that may become relatively large, a few
> > megabytes maybe. maybe I should put this database on the sd card to
> > save internal storage.
>
> > With SQLiteDatabase.openOrCreateDatabase() this should be quite
> > straightforward.
>
> > But I'd like to use SQLiteOpenHelper since it takes care of creating
> > and updating the db so nicely. Unfortunately SQLiteOpenHelper seems to
> > be restricted to the internal storage.
>
> > Now I have noticed that SQLiteOpenHelper uses
> > Context.openOrCreateDatabase() and Context.getDatabasePath()
> > internally.
>
> For some reason, getReadableDatabase() uses getDatabasePath(), but
> getWriteableDatabase() does not. That seems...odd.
>
> > Would it be too much of a dirty hack if I wrote my own ContextWrapper
> > that implements these methods to create a database on the sd card? Or
> > would this be a legitimate use of the API?
>
> That might work, but then if they change the implementation of
> SQLiteOpenHelper, you might not realize that you also need to change
> your ContextWrapper somehow to match.
>
> Since SQLiteOpenHelper is not that big and is only directly used by your
> app, another approach is to grab their code, modify it to create an
> SDOpenHelper that supports your database-on-SD model, and use that.
> Assuming SQLiteOpenHelper is not using any package-private methods, of
> course...
>
> --
> Mark Murphy (a Commons
> Guy)http://commonsware.com|http://twitter.com/commonsguy
>
> _Android Programming Tutorials_ Version 1.0 Available!
--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
