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, > 2009http://www.bignerdranch.com/schedule.shtml --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
