2

I have a ContentProvider backed up by SQLiteDatabase and it has a rather common implementation, i.e:

class MyContentProvider extends ContentProvider {
    public void update(...) {
        // write stuff to DB
        //...
        // done writing stuff

        getContentResolver().notifyChange(uri,null);
    }
}

I also use a CursorLoader to perform query and display its results in adapter/listview.

No thread synchronization is done in my ContentProvider.

It is not very clear for me what happens in the following case:

  1. I start some custom non-ui thread and call update() to change some values in DB inside this thread.
  2. This update() causes notifyChange(...) to be called
  3. My CursorLoader picks up this change and updates adapter, which updates a ListView

Is the above scenario OK from a thread-safety perspective? I mean, look, values are written using one thread (non-ui), then same thread notifies about changes and lastly changes are picked up by CursorLoader which I suspect uses some other background thread to load its data.

Do I need to do some manual thread synchronization or will it just work? (Android may already be smart about all this stuff)

dimsuz
  • 8,969
  • 8
  • 54
  • 88
  • http://stackoverflow.com/questions/7481978/how-to-create-a-thread-safe-contentprovider?rq=1 Also read the Vogella 5.4. Security and ContentProvider at http://www.vogella.com/tutorials/AndroidSQLite/article.html – Erik Jan 22 '14 at 11:34
  • Yes, I've read all this. I'm mainly interested, will notifyChange() cause some synchronization to happen before loader picks it up. If it does, then I do not have to worry. If it doesn't, then I need to be careful :) – dimsuz Jan 22 '14 at 11:51
  • In this comment it is noted that notifyChange is thread-safe: http://stackoverflow.com/questions/7478181/once-a-content-provider-is-updated-how-can-i-inform-all-listeners-there-was-an#comment9050532_7478223. But SDK docs do not mention it... – dimsuz Jan 22 '14 at 11:55

0 Answers0