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

--~--~---------~--~----~------------~-------~--~----~
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