OrmLite Loaders and database connection loss at configuration changes about ormlite-android HOT 12 OPEN

So it is static or something? Is there no way to detect the application is starting and specifically clear it or re-create it?

from ormlite-android.

You're thinking about a workaround in my application code, right ?

My point of view is that the use case I describe is really simple : one activity which uses one loader. That's it. This use case should work with OrmLite loaders because it is the simpliest use case we can imagine for loaders use !
Android Loaders are designed to load data regardless of activities life cycle, partly to not reload data at each configuration change. When OrmLite Loaders depend on activities life cycle because of the database connection management, they don't comply with android loaders "contract".

So I think the best solution is to find a correction in the OrmLite library code itself. As I said before, the solution may be to make the OrmLite loaders retain the database connection. What do you think of this ?

from ormlite-android.

I don't think you should retain the database connection. I don't think that's proper. Can you find some Android docs which say otherwise?

from ormlite-android.

When I say "retain the database connection", I mean "call OpenHelperManager.getHelper and OpenHelperManager.releaseHelper".
The Android docs http://developer.android.com/guide/components/loaders.html and http://developer.android.com/reference/android/content/Loader.html don't mention anything about database because Loaders mecanism abstracts the data source.
What other than mine solution would you propose to solve the database connection issue ?

from ormlite-android.

@j256 Do you agree that OrmLite must be compliante with the use case I described ?

from ormlite-android.

I think your application must be compliant. I'm not sure I agree that it's ORMLite responsibility to protect against it. This is the first time that I've heard of this problem. Feel free to take a poll on the android mailing list however.

from ormlite-android.

To be 100% clear on this. You can, and should, keep your db connection open. I wrote the original version of the base activities that open/close the db connection, and have since done a lot of research and testing on this. You should keep a singleton pointing at a single open helper instance.

See: http://stackoverflow.com/a/3689883
And: http://touchlabblog.tumblr.com/post/24474750219/single-sqlite-connection
And (more formally): http://stackoverflow.com/a/12715032

You are correct. I imagine if your db is closed on rotate, your loader is going to freak out if its holding onto Dao. If you're going to change things, though, you'll need to change ALL of your base classes. The key to good DB health is one OpenHelper instance.

I just realized how old this bug was, but its probably good reading if somebody else is having the issue.

This also improves my argument to deprecate the helper activities ;)

from ormlite-android.

OK, I understand.
The problem here is that the documentation encourage to do what I did, I mean use OrmLiteBase classes to manage access to the database helper whereas it seems that it is not the right way to go.
So I agree, the helper activities may be deprecated and the documentation updated to explain the good way of doing (using a subclass of OrmLiteSqliteOpenHelper as singleton ?).

from ormlite-android.

I'm with you. I have another potential solution, but I'm reluctant to put more work into the helper classes. Its sort of complex to explain, unless you have a deep understanding of Android threading. Essentially, queue the closing call in the helper on the main thread, so by the time it gets there, if you did a rotate, the new activity would've incremented the db counter, and it won't close. TBD.

from ormlite-android.

It's becoming quite complicated !!
Why not letting OrmLite Loaders be connected to OpenHelperManager like OrmLite Activities are ?
The dao parameter in constructor would be replaced by a class parameter to let them call getDao() on the database helper (obtained thanks to the OpenHelperManager) and manage their own dao instance ?

from ormlite-android.

@kpgalligan , what about initializing the singleton in Application.onCreate() ? This would permit to remove the context parameter in the singleton getInstance() function (which is only used for initialization).

from ormlite-android.

@kpgalligan , what do you think of my previous proposals ?

from ormlite-android.