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