Downloading it once is probably the best approach, and also allows you
to release updates to the database that your app can check for. You
could reduce the bandwidth some by compressing it and having the app
decompress it.

On Dec 3, 1:50 pm, 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, 
> > 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
-~----------~----~----~----~------~----~------~--~---

Reply via email to