Your best option is to copy it to the SD card. I don't see any chance if supporting SQLite on an database embedded in a .apk any time soon. Ignoring whatever issues there are in SQLite just to do this kind of thing, I wouldn't want to count on Android 3.x running who knows what later version of SQLite being able to operate on a SQLite database from 1.0 without being able to do some kind of upgrade process on it.
Also, just to start to be able to support this, you would need to store the database in your .apk without compression. If you take the approach of copying it to the SDCard, you can keep it in the .apk as a normal compressed file, which I would bet would make it significantly smaller (the SQLite database format is almost certainly designed for efficient access and not optimal size). As far as app installers go, this is something we actually have deliberately avoided. In our current implementation, a person can "turn off" a .apk and the system will behave as if it never existing, and you can later "turn it on" and it will come back as you left it. I would be strongly opposed to anything that broke that model. Doing dependency tracking, so that if you install app A you will also get app B that it needs, is another issue, and something we will certainly address hopefully sooner rather than later, though most of that will probably be in the Market. On Wed, Dec 3, 2008 at 10:50 AM, burton miller <[EMAIL PROTECTED]>wrote: > > i'm not trying to be difficult - i've been a desktop developer for > many years - but the desktop systems have a LOT more storage, so the > paradigm is fundamentally different than a phone. > > i'm very hesistant to ship a 4.5mb database and duplicate it all > inside the tiny sliver of user storage android provides. > > right now i'm planning on doing a two-stage installation where the > application downloads the database from the internet when it first > runs. and probably push it onto the sd card if i can figure out how > to make database api work on something not located in data/data/ > package/databases. > > if anyone has any practical solutions that are better than this, then > i'd like to hear them. > > On Dec 3, 4:56 am, Mark Murphy <[EMAIL PROTECTED]> wrote: > > burton miller wrote: > > > these solutions will not work for me. > > > > > i have a 4.5mb database, which i do not want to duplicate by copying > > > it out of the apk and into a directory. > > > > > copying it from the web could potentially be very slow as well. > > > > > i can't believe that there is not a better solution to this extremely > > > common situation. many, many apps will need to come with a pre- > > > populated database. > > > > If you were to write a Windows application, and you were to distribute a > > pre-populated database, you would bundle the database in the application > > installer (.EXE, .MSI) and would install it to your targeted location. > > If the user elected to hold onto the application installer, you would > > have the same scenario as with Android and the APK: two copies of the > > database (master in the installer, working copy outside it). > > > > If you were to write a Linux application, and you were to distribute a > > pre-populated database, you would bundle the database in the application > > package (RPM, DEB, etc.) and would install it to your targeted location. > > If the user elected to hold onto the application package, you would have > > the same scenario as with Android and the APK: two copies of the > > database (master in the package, working copy outside it). > > > > If you were to write a desktop Java application, and you were to > > distribute a pre-populated database, you *might* bundle the database in > > the JAR and would copy it to your targeted location on first run. That > > way, you can still have an "executable JAR". Here, again, you would have > > the same scenario as with Android and the APK: two copies of the > > database (master in the JAR, working copy outside it). > > > > So, it's not like the Android model is singularly unusual. It's not > > optimal, particularly for the tiny number of applications shipping large > > databases with their apps, but it's not preposterous, either. > > > > Now, don't get me wrong. It'd be nice if there were a higher-order > > packaging option beyond the APK -- something that could bundle and > > install one or more APKs plus other files (e.g., databases), after which > > the meta-package could get deleted. This would solve a bunch of > > problems, not the least of which could be the issue of APK dependencies > > (e.g., Application X requires Remote Service Y, which might already be > > installed via some other app). However, I'm not terribly shocked that > > it's not in Android 1.0r1. > > > > At some point, somebody will have the itch for this sort of thing and > > will scratch it, whether that "somebody" is on the core Android team or > > working outside of it. > > > > -- > > Mark Murphy (a Commons Guy)http://commonsware.com > > > > Android Training on the Ranch! -- Mar 16-20, 2009 > http://www.bignerdranch.com/schedule.shtml > > > -- Dianne Hackborn Android framework engineer [EMAIL PROTECTED] Note: please don't send private questions to me, as I don't have time to provide private support. All such questions should be posted on public forums, where I and others can see and answer them. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com 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 -~----------~----~----~----~------~----~------~--~---
