When using a LoaderManager, do I still manage my database writes the way I have in the past and let the Loader pick up the changes? I am in the process of converting and adding functionality to an app and I am still getting used to the Android platform.
Asked
Active
Viewed 589 times
1 Answers
1
If you are using CursorLoader
, and you do all your database updates via the ContentProvider
you used with CursorLoader
, the loader and its Cursor
will be notified of changes, so everything will be handled for you.
If you are not using CursorLoader
, it is your responsibility to somehow update your own Cursor
. For example, my LoaderEx project has a SQLiteCursorLoader
that works directly with a SQLiteOpenHelper
, and it offers insert()
, update()
, delete()
, and execSql()
methods on the Loader, so we can update the Cursor accordingly.

CommonsWare
- 986,068
- 189
- 2,389
- 2,491
-
Thank you, this helped to clear up some questions I had. I was going to use the ArrayList returned by my DBAdapter class and work on a custom loader but I think I will just convert to a contentprovider and move forward with that model. – ewjames Mar 07 '12 at 19:12
-
Actually I went back and re-read Chapter 18 and now I have a good picture of what you are referring to. Thank you again. – ewjames Mar 07 '12 at 22:21
-
One more question on this as I dive deeper; could one extend the `SQLiteCursorLoader` and either override `buildCursor` or ad a new function to use `db.getReadableDatabase().query`? So I could leverage the code I have or simply take the cursors returned from the DBAdapter helper classes I have already built. – ewjames Mar 07 '12 at 23:23
-
@ewjames: I never use `query()` myself, so I scratched my itch with `rawQuery()`. But you could augment `SQLiteCursorLoader` to have additional data members and a different constructor, with `buildCursor()` examining the data members and doing a `query()` or `rawQuery()` as appropriate. Patches are welcome. :-) – CommonsWare Mar 07 '12 at 23:30
-
I implemented a solution out of the box to get my feet wet and I ran into an issue so I opened a new question [here](http://stackoverflow.com/questions/9614530/using-a-listfragment-with-a-simplecursoradapter-with-the-holder-pattern) – ewjames Mar 08 '12 at 08:05
-
@CommonsWare I noticed in your `LoaderEx` implementation (specifically in the [**`ContentChangingTask`**](http://bit.ly/MWLr7I)) you have the `Loader` call `onContentChanged()` on itself to notify that a change has been made (thus, signalling the `Loader` to perform a new asynchronous query for the updated data). This doesn't seem like the best solution though... in this case, all SQL transactions *must* go through the `ExecSQLTask` or else the `Loader` will never be notified that changes to the database have been made. – Alex Lockwood Jul 25 '12 at 18:28
-
@AlexLockwood: "in this case, all SQL transactions must go through the ExecSQLTask or else the Loader will never be notified that changes to the database have been made" -- correct. "Is there an easy way to set up a more external means of notifying" -- call `onContentChanged()` yourself on the `SQLiteCursorLoader`. – CommonsWare Jul 25 '12 at 18:32
-
@AlexLockwood: "but is there a way to do this from a lone SQLiteDatabase instead?" -- no, as `SQLiteDatabase` knows nothing about a `SQLiteCursorLoader` and has no observer-style event interface. Whoever uses `SQLiteDatabase` is responsible for calling `onContentChanged()` on the `SQLiteCursorLoader`. – CommonsWare Jul 25 '12 at 18:33
-
@CommonsWare your incredibly quick comment threw me off, and I quickly deleted the one I posted about 10 seconds after your initial response. Sorry about that -_-. Anyway, I know you are one of those Android people who isn't exactly a fan of private `ContentProvider`s... but could the `ContentResolver`s "observer-style event interface" be an advantage of using one? The `CursorLoader` seems a lot cleaner in the sense that it doesn't require the client to make direct calls to `onContentChanged()`. – Alex Lockwood Jul 25 '12 at 18:38
-
@AlexLockwood: "but could the ContentResolvers "observer-style event interface" be an advantage of using one?" -- it is one of the benefits, yes. – CommonsWare Jul 25 '12 at 18:58
-
@CommonsWare I'm back with one more question :). In the LoaderEx's [README.markdown](http://goo.gl/9q7De), you mentions that future work might "Support for synchronization on the SQLiteDatabase". How exactly were you thinking of doing this? From what I can tell, everything will be fine so long as the client is never using more than one `SQLiteDatabase` at once... but obviously LoaderEx can't enforce this requirement no matter what you do. Am I missing something? – Alex Lockwood Oct 09 '12 at 17:13
-
@AlexLockwood: It's quite likely that I simply failed to remove that bullet after adding the `insert()`, `update()`, `delete()`, and `execSQL()` methods on `SQLiteLoader`. Leastways, right now, I cannot recall what else I might have been thinking there. Sorry. – CommonsWare Oct 09 '12 at 17:17
-
@CommonsWare OK cool... thanks for getting back to me so fast (again). :) I have one more question actually, if that's OK. I've been thinking a lot about the limitations of LoaderEx in that it can't receive content change notifications from outside of the `Loader`. Do you think it is possible to implement some sort of third-party global notification system possible for `SQLiteDatabase`? I've been looking for an excuse to write a third-party library that does this (since I've never written one before :D... ya, I'm a noob) so that's why I ask. :) – Alex Lockwood Oct 09 '12 at 17:26
-
@AlexLockwood: "Do you think it is possible to implement some sort of third-party global notification system possible for SQLiteDatabase?" -- I suppose that depends on your definition of "global". You could try to fork `SQLiteDatabase` and `SQLiteOpenHelper` to try to create ones that offer some sort of notification mechanism. It's not even out of the question that you could pull it off with a subclass of `SQLiteDatabase`. I just haven't looked at this much. – CommonsWare Oct 09 '12 at 17:36
-
@CommonsWare Subclassing `SQLiteDatabase` was my first though as well, but it's `final` unfortunately. :/ Anyway, I'll continue thinking about this/experimenting. I was just wondering if you had already looked into it. :) (Thanks for the help too, as always!) – Alex Lockwood Oct 09 '12 at 17:48