Originally I intended at developing an app for 2.2 and above, but seeing as 2.3 offers quite an improvement on the database aspect I might as well slap on a gingerbread version.
The guide which you linked is what I first thought of doing, but as you stated, it seems to have stability issues. Your suggestion seems to be quite straight forward and stable, so I'm going to follow your approach. Thanks for the advice! On Tuesday, July 10, 2012 4:46:51 PM UTC+2, Nobu Games wrote: > > You can load pre-made SQLite database files without a problem. If you want > to use the > SQLiteOpenHelper<http://developer.android.com/reference/android/database/sqlite/SQLiteOpenHelper.html>for > that you need to add another meta data table required by it for > localization purposes. The approach is described in following blog article: > http://www.reigndesign.com/blog/using-your-own-sqlite-database-in-android-applications/ > > However, quite a few people who used that approach were complaining about > exceptions and other problems on the first attempt at opening that pre-made > file. Therefore and for other reasons I don't use SQLiteOpenHelper and make > instead direct use of > SQLiteDatabase<http://developer.android.com/reference/android/database/sqlite/SQLiteDatabase.html>and > its openDatabase methods. > > The advantage of that is that you can specify any path for your database > file as opposed to SQLiteOpenHelper which only allows you to open database > files in a specific app directory. On top of that, you also don't need to > add any meta data. > > I'm currently working on an app with a static database which is a > dictionary I created on my PC using SQLite 3. I can load that file without > a problem on Android. > > I assume you're going to bundle that big database file as an asset with > your app. As far as I know file sizes > 1MB can cause problems for Android > versions < 2.3. If you want to support pre 2.3 Android devices you'll need > to split your database file into several smaller files of about 1MB size. > You can use the Linux command line tool split for that: > > split --bytes=1m -d /path/to/big/asset /path/to/output/filename-prefix >> >> > In your app you need to read these asset file chunks and join them again > into a single file. > > As for using an in-memory solution for all your data: I really wouldn't do > that, since it sounds like you're dealing with an amount of data that could > easily consume most of the available heap space for your app. > > > On Monday, July 9, 2012 3:28:11 PM UTC-5, Hydde wrote: >> >> Hi, >> >> I'm quite new to Android and Java programming. I'm currently designing >> an app which is supposed to utilize a medium-size database (6-7MB). This >> database is static meaning there won't be any updates/deletes or inserts to >> it. It's basically a bulk of data. >> >> I've been googling around and don't seem to find a solid way of >> integrating a premade DB into an app. Most guides seem to start from an >> empty DB which builds up as the app runs. I've only found a single solid >> guide on how to implement a premade database into an app and it basically >> causes the DB to double in size. >> >> So now I'm thinking of just loading the data completely into the memory >> as multiple sorted static array strings and querying those arrays through >> java logic. (Note that reading speed of the data is absolutely vital). But >> knowing that memory available to apps is limited I'm in doubt. >> >> Are there any other advantages/disadvantages to this approach? >> > -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] 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
