I looking at 'enhancing' the Loader code put forward by jc on this list and wanted to get feedback from anyone who might already be using it.
I've noticed that most of the CursorLoaders and example Ormlite Loaders seem to depend on side channel notifications of data being updated in the database. Per this
code which jc shared with the list, the method registerContentObserver is called on Cursor. Im my limited testing, this does not seem to fire for my operations executed via a Dao. After some digging into the Android source of AbstractCursor and SQLiteCursor, it appears that this is because each cursor gets its own registered observer but separate actions against the database do not reuse the same Cursor and don't seem to trigger the previous Cursor's observers events. A similar conclusion was reached in
this Stackoverflow question.
I'm exploring ways to fix this and, based on Commonware's Loaderex package, through about holding a List of weak references to Loaders created using the Dao as the hub. When a getXXXLoader method is called against the Dao, its added to the list. When a Dao method (create, update, delete) is used, the integer return value is checked to see if it is greater then 0. If it is, all loaders are nudged to reload their datasets.
I'm throwing this out there to see if a) people have the existing Cursor method working by some other method or b) if this seems like a good way to solve the issue. The other way I have been tossing around is described in the stackoverflow question. Basically, we'd generate a unique URI for each Dao table and then piggyback on the Content Provider system to do notifications. The major difference is that, instead of having the Dao directly notify the Loader, the Dao would notify the system that the data at the generated Uri has changed and the loaders would be notified as a consequence.
Any feedback?
Nick