I am developing an Android App and thought of using an ORM to leverage some of the database work, i've seen a few and they all seem good for the job, now I only have one main issue left, i haven't found a way of setting the database location on runtime.
For example, im gonna talk about a common (and in this case, very real) scenario lets suppose your app needs to work completely offline, and the user downloads the database the app needs, a common guideline is to provide some sort of file explorer so the user can specify the data directory.
Well, let's suppose im using ActiveAndroid ORM, i've set up everything according to the guide, and I specify the name of the database in the AndroidManifest, i can even set a static path in there, say for example, "/mnt/sdcard/data/data.db" and it will work on using the existing database, i just haven't found the way of doing something like
ActiveAndroid.location = customLocation;
where customLocation is the path selected by the user on the Preferences, namely, the custom location of the database.
Any help appreciated.
I found a workaround that works for me, its nothing too complicated but i haven't seen this particular issue addressed nowhere.
Instead of initializing your ActiveAndroid connection in the AndroidManifest via the
android:name
attribute, don't specify any name or metadata attribute there, now, the official documentation states you can initialize ActiveAndroid on runtime via
ActiveAndroid.initialize(this)
Well, there is a pretty handy class called Builder which can be accessed with a Configuration class, the one in ActiveAndroid, not the one in android.content.res, and with a Builder object you can specify a few things, namely, the
setDatabaseName(String name)
attribute, where you can then use the custom path of your database, and then initialize ActiveAndroid like this
ActiveAndroid.initialize(builder.create())
where the create() method returns a Configuration object
And that does it! Now you can use that pre-populated database with ActiveAndroid wherever your users decided to place it.
Related
Background: I'm taking an Android class right now and part of our final project requires retrieving data through an SQLite query. We're using the Chrome browser history to populate a RecyclerView. We're working off of an AVD and changed permissions on the history file (since, obviously, this isn't something that would normally be done) to make it readable. We have to use a SQLite query to get the data, though, and then do other stuff with it inside the app.
I've been digging around for the past couple of days and have found quite a few different examples for database connections in Android but they all seem to have a lot of unnecessary bloat that I don't need. I don't need to create or delete tables, I'm not adding or changing entries at all, I just need to query and get information back to play around with. I looked through the SQLiteDatabase documentation and the only thing that kind of looked like what I wanted would involve the beginTransaction() and endTransaction() methods. But I wasn't entirely sure.
I'm definitely not trying to like, covertly get others to do the work for me, but I wonder: is there a way I can query the database directly with a few lines in my code or from a relatively simple method? Or do I need to go through and implement something resembling the various database helper classes I've seen with all the extra functionality I don't need right now? Feel free to ask any follow up questions that may arise, if any. Thanks for any help you all can give!
You probably want to use one of the SQLiteDatabase.openDatabase() methods, with the OPEN_READONLY flag. Then, you can use methods like query() or compileStatement() on the returned SQLiteDatabase object.
I am very new to ORMs and presently trying to implement green Dao to manage by DB operations.
I want few good examples to work upon to understand its working but it seems I get stuck after DaoGeneration.
After this process I am able to see my generator files inside the desired directory. Can anyone tell me what to be done next. Or please suggest me some good documentation.
This is a good place to start. It's the examples provided by greenDAO themselves.
https://github.com/greenrobot/greenDAO/tree/master/DaoExample/src/main/java/de/greenrobot/daoexample
You can notice that except for NoteActivity.java, all other java files were generated by the DaoGenerator.
Some common practice:
These lines can be put in your Application scope. Means you can have one session for the whole application life cycle, according to this answer from greendao
Save your Query to reuse to gain performance.
Some Common errors:
When deleting record from DB, make sure to detach it from session. Otherwise the object is still in cache and next time you want to get record by ID and you thought this is already overwritten by a new object. Nope.
I want to copy a premaded database in user's device. then use it in the android App.
but I don't know where is the best place for that. (a place that I can copy file to it)
for example:
I have a database named "FoodsDB.db" in assets folder
When application starts for first time, it copies the DB from assets to user's Device
Then in DatabaseHelper address it and use it
Right off the bat without knowing exactly your code I'd try and guess that when you say "I don't want to submit changes" means you shouldn't invoke SaveChanges(). Shouldn't you try to completely discard the entities, then? I doubt it's that simple, but I post this nonetheless.
After you've added the example code I can see it's different then I thought. You won't be able to use a rollback (see unit of work pattern). What you need here is a PARTIAL undo, which is different then the full-scale undo I initially proposed by throwing away the entire context.
Look here for an excellent solution to your problem:
Entity Framework .Remove() vs. .DeleteObject()
I'm developing a library that will be able to be used across multiple apps. It serves the exact same function in each, and one of the goals of the library is to be as easy and painless to use as possible. In that way, I was hoping to use a SQLite db to store some important information relevant to the library, but NOT to the host app. I searched around and couldn't find anything confirming or denying the ability for libraries to have their own databases. Does anyone know if it is possible?
Thanks a lot.
Well, that depends upon what you mean by "the ability for libraries to have their own databases".
There is nothing stopping an Android library project -- or even a plain Android-compiled JAR -- from using SQLiteDatabase, SQLiteOpenHelper, and kin. So, from a code standpoint, the library can have its own database. You will need a Context object from the host app, at least for use with SQLiteOpenHelper, though.
That is because, from a file standpoint, the library does not exist outside of its hosting app. Hence, the database file will be stored in the app's portion of internal storage by default. You will need to take some steps to try to minimize the odds of collisions on database file name (e.g., mangle your library's package name into the filename), so the host app does not attempt to accidentally work with your library's data. The Context is supplied to SQLiteOpenHelper mostly so that it can call methods like getDatabasePath() to figure out where to put the database file.
Also, bear in mind that the host app can access your database, just as it can access its own. Please make sure that you document the rules regarding this database (e.g., do not use it directly, but use the library's API instead).
I have seen this question here, and was wondering if the same method of "pre-loading" a database for an android application still works. I will be developing my application on the 2.2 platform, but I want to make sure that going forward I will not have to completely redesign if I use this method.
Secondly, is this the best method if I have unchanging data that needs to be looked up? Or is XML a better choice?
Example: I have a Car, a car has attributes like weight, color, make, model, engine, etc. these all need to be accessed in a lookup but the attributes and entries will never change (and if they do, they change as such a slow rate that I would release an update to add the few things that changed).
Thanks for any help.
Yes, the pre-loading method mentioned in the blogpost that article links to (http://www.reigndesign.com/blog/using-your-own-sqlite-database-in-android-applications/) still works for me after some tweaks prompted by a number of force closes from users. There were some issues with the database not being found on the Desire HD, which caused problems. It was difficult to isolate what exactly the problem was, but I think it was the file locations that was the problem. You should define
private static String DB_PATH = Environment.getDataDirectory() + "/data/your/app/package/databases/"
instead of
private static String DB_PATH = "/data/data/your/app/domain/databases/"
I also changed all database access to writeable as I had read that caused problems, but not sure if that was really the issue.
In terms of your second question, I would say it depends on exactly how much data you have. If it's a lot of data, you're probably better off using a database anyway for performance reasons. There are pitfalls to using the SQLite APIs, such as apostrophes in the fields (make sure you use the convenience methods query, update and insert rather than rawQuery). But I'm sure there are with XML too - I don't think there's any "correct" method more what you are most comfortable with - i.e. do you prefer working with databases or raw XML? If neither, and you're not planning to do major updating or querying, I would use XML, or even JSON, because of the reasons above and what Jodes alludes to.
The answer is not simple, you need to cross reference the version of SQLite used in different phones with the file format used for those versions.
A previous SO question showing difficulties in determining SQLite versions are here:
Version of SQLite used in Android?
And a page listing differences in file formats for different SQLite versions is here:
http://www.sqlite.org/formatchng.html