Friday, June 14, 2013

Using Mark Murphy's SQLiteCursorLoader in Android Studio

For the current app I am working on, I had reused some older code to provide a simple ListView populated from an SQLite database.  This code used the now deprecated "startManagingCursor" functionality, and I was hitting the common "trying to requery a cursor that is already closed" error.

For not a little while, Google has been pushing folks to move on up and use their "Loader" framework instead - for one reason, because the older way does all of its work on the main UI thread.  I have never seen any performance issues with the older way, and the list in my case is small.  However, rather than track down the tedious cursor issue in the midst of the deprecated classes, I decided it was time to go ahead and use the updated approach that is supposed to handle the tedium for me.

Finding a straightforward approach for doing this for the simple case of hitting against a little SQLite database was not as straightforward as I had anticipated.  It took me a little bit of reading to finally converge on an implementation that Mark Murphy did.  He has one version that works on HoneyComb and later, and one version that uses the v4 compatibility libraries (which is what I used).  He also has a demo project that shows exactly how to use it.  His project is on github here.  I cloned the project, imported it into eclipse and built the jar, then referenced that as a library in Android Studio.

The question of how to deal with this simple case came up in a google groups a while back (amongst other places), and, because of some trickiness in the implementation,  Google's Diane Hackborn suggested ("please, please, please") that you take the source for their CursorLoad class and make a trivial change where it returns the cursor.  I did not do a complete diff, but it looks like Mark's library definitely started there, although he (thankfully) added some extra functionality for CRUD stuff.

Note that there might be an issue with CursorLoaders and orientation changes - after an orientation change, the loader might not get reset, and a npe would occur.  This was discussed in this google groups thread from almost two years ago, and Mark entered a yet-to-be-resolved issue for it.

I also tried to port the project to Android Studio as a library project, but this started hitting some scattered strangeness, no doubt because I am also yet to dive into gradle to any degree yet.  I believe that there are some still some gaps in migrating projects to Android Studio from Eclipse, and in managing library projects in Android Studio... but some of these issues might be fixed in the latest (0.1.5 version) of Android Studio that I just now updated to.

No comments:

Post a Comment