[android-developers] Re: Including SQLite database with application
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 -~--~~~~--~~--~--~---
[android-developers] Re: Including SQLite database with application
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 -~--~~~~--~~--~--~---
[android-developers] Re: Including SQLite database with application
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-developers] Re: Including SQLite database with application
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 -~--~~~~--~~--~--~---
[android-developers] Re: Including SQLite database with application
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. does anybody have anything else? google guys? On Nov 16, 9:37 am, G [EMAIL PROTECTED] wrote: Do you think you could include some sample code for how to execute an sql script thats been included as raw? On Nov 15, 7:59 pm, Dan B. [EMAIL PROTECTED] wrote: I think your best 2 options are as the previous poster stated. 1) package the db file as a raw resource, then just use a file stream to read it from the resources and write it out to the location you plan to access it. 2) generate a .sql file and package that as a raw resource, then just read and execute the .sql file to build the database on the fly at first run option 2 is probably the better. another option would be to host the db file from an http location and just grab it and copy it to the location you plan to use it, this will make the APK file smaller, but requires you to have a stable web server to store and host the db file On Nov 15, 4:41 pm, Stu [EMAIL PROTECTED] wrote: Hi Mark, thanks for your help. I guess I'll just have a play around with a couple of those suggestions and see which one works for me. :) Regards, Stuart. On Nov 15, 9:57 pm, Mark Murphy [EMAIL PROTECTED] wrote: Stu wrote: I'm unable to find how I can ship my database with my application. I don't really want to populate the database at the first run, it just seems a bit pointless when I could prevent this time consuming activity by including a pre-populated db. AFAIK, applications are not unpacked from the APK when installed, and SQLite has no notion of working with a database file given just an InputStream, which is all you can get for things packed in your APK. I am only aware of three options: 1. Bundle a database as either an asset/ or a res/raw/, then use appropriate methods to get an InputStream on the database, and copy it somewhere where you can read/write to. I'm uncertain as to whether this approach is a good idea. 2. Use the sqlite3 console utility (or an equivalent tool) to dump the database a set of SQL statements required to rebuild it. Bundle that file with your application (e.g., in res/raw/) and execute that script on first run. This may feel pointless, but done properly, you can integrate all this into your build process, so you don't, as a developer, have to deal with anything -- you just edit your master database copy on your development PC. 3. Use the classic approach of just populating the tables yourself in Java code as part of creating the database. If the table is bigger than a few rows, I'd probably go with #2. But, that's just me. -- Mark Murphy (a Commons Guy)http://commonsware.com Android Training on the Ranch! -- Mar 16-20, 2009http://www.bignerdranch.com/schedule.shtml-Hidequoted text - - Show quoted text - --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[android-developers] Re: Including SQLite database with application
Do you think you could include some sample code for how to execute an sql script thats been included as raw? On Nov 15, 7:59 pm, Dan B. [EMAIL PROTECTED] wrote: I think your best 2 options are as the previous poster stated. 1) package the db file as a raw resource, then just use a file stream to read it from the resources and write it out to the location you plan to access it. 2) generate a .sql file and package that as a raw resource, then just read and execute the .sql file to build the database on the fly at first run option 2 is probably the better. another option would be to host the db file from an http location and just grab it and copy it to the location you plan to use it, this will make the APK file smaller, but requires you to have a stable web server to store and host the db file On Nov 15, 4:41 pm, Stu [EMAIL PROTECTED] wrote: Hi Mark, thanks for your help. I guess I'll just have a play around with a couple of those suggestions and see which one works for me. :) Regards, Stuart. On Nov 15, 9:57 pm, Mark Murphy [EMAIL PROTECTED] wrote: Stu wrote: I'm unable to find how I can ship my database with my application. I don't really want to populate the database at the first run, it just seems a bit pointless when I could prevent this time consuming activity by including a pre-populated db. AFAIK, applications are not unpacked from the APK when installed, and SQLite has no notion of working with a database file given just an InputStream, which is all you can get for things packed in your APK. I am only aware of three options: 1. Bundle a database as either an asset/ or a res/raw/, then use appropriate methods to get an InputStream on the database, and copy it somewhere where you can read/write to. I'm uncertain as to whether this approach is a good idea. 2. Use the sqlite3 console utility (or an equivalent tool) to dump the database a set of SQL statements required to rebuild it. Bundle that file with your application (e.g., in res/raw/) and execute that script on first run. This may feel pointless, but done properly, you can integrate all this into your build process, so you don't, as a developer, have to deal with anything -- you just edit your master database copy on your development PC. 3. Use the classic approach of just populating the tables yourself in Java code as part of creating the database. If the table is bigger than a few rows, I'd probably go with #2. But, that's just me. -- Mark Murphy (a Commons Guy)http://commonsware.com Android Training on the Ranch! -- Mar 16-20, 2009http://www.bignerdranch.com/schedule.shtml-Hide quoted text - - Show quoted text - --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[android-developers] Re: Including SQLite database with application
Stu wrote: I'm unable to find how I can ship my database with my application. I don't really want to populate the database at the first run, it just seems a bit pointless when I could prevent this time consuming activity by including a pre-populated db. AFAIK, applications are not unpacked from the APK when installed, and SQLite has no notion of working with a database file given just an InputStream, which is all you can get for things packed in your APK. I am only aware of three options: 1. Bundle a database as either an asset/ or a res/raw/, then use appropriate methods to get an InputStream on the database, and copy it somewhere where you can read/write to. I'm uncertain as to whether this approach is a good idea. 2. Use the sqlite3 console utility (or an equivalent tool) to dump the database a set of SQL statements required to rebuild it. Bundle that file with your application (e.g., in res/raw/) and execute that script on first run. This may feel pointless, but done properly, you can integrate all this into your build process, so you don't, as a developer, have to deal with anything -- you just edit your master database copy on your development PC. 3. Use the classic approach of just populating the tables yourself in Java code as part of creating the database. If the table is bigger than a few rows, I'd probably go with #2. But, that's just me. -- 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 -~--~~~~--~~--~--~---
[android-developers] Re: Including SQLite database with application
Hi Mark, thanks for your help. I guess I'll just have a play around with a couple of those suggestions and see which one works for me. :) Regards, Stuart. On Nov 15, 9:57 pm, Mark Murphy [EMAIL PROTECTED] wrote: Stu wrote: I'm unable to find how I can ship my database with my application. I don't really want to populate the database at the first run, it just seems a bit pointless when I could prevent this time consuming activity by including a pre-populated db. AFAIK, applications are not unpacked from the APK when installed, and SQLite has no notion of working with a database file given just an InputStream, which is all you can get for things packed in your APK. I am only aware of three options: 1. Bundle a database as either an asset/ or a res/raw/, then use appropriate methods to get an InputStream on the database, and copy it somewhere where you can read/write to. I'm uncertain as to whether this approach is a good idea. 2. Use the sqlite3 console utility (or an equivalent tool) to dump the database a set of SQL statements required to rebuild it. Bundle that file with your application (e.g., in res/raw/) and execute that script on first run. This may feel pointless, but done properly, you can integrate all this into your build process, so you don't, as a developer, have to deal with anything -- you just edit your master database copy on your development PC. 3. Use the classic approach of just populating the tables yourself in Java code as part of creating the database. If the table is bigger than a few rows, I'd probably go with #2. But, that's just me. -- 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 -~--~~~~--~~--~--~---
