Handling SQLite tables and cursors on Android

Question

I find it difficult to optimize backward compatibility, complexity and best practices for processing SQLite databases on Android. I found two not obsolete ways to manage SQLite databases and cursors:

• Directly through android.database.sqlite
• ContentProvider , CursorLoader and LoaderManager

I am trying to develop future proof of a future database. This means that I would like to implement the best practices that Google promotes. I found a tutorial on implementing ContentProvider and LoaderManager .

If I follow the suggestions of Lars Vogels, my code is blown up by duplication and unnecessary complexity. This makes sense for some tables in my database. But it would be useless to implement this for a mapping table with three fields (for example). Also, I am having problems with the ActionbarSherlock and the ActionbarSherlock callback interface (there is a solution there, but that will double my data processing classes).

Direct processing of the database and cursors using android.database.sqlite causes problems with resource management (close cursors!) And makes me responsible for processing tasks.

My questions:
How do you handle SQLite databases on Android?
When do you go the extra mile and implement ContentProvider and LoaderManager ?
How do you maintain backward compatibility?

My current approach:
I created a class that separates database I / O (via android.database.sqlite ) from actions. All methods open and close the cursors that they use during their execution (outside of my actions), and return objects or data as necessary (instead of the cursor). I / O operations are performed in AsyncTasks . This approach seems very outdated.

Answer 1

I recently had the same simple problem with sqllite / content provider, and it looks like the content provider is the most common approach to solving the problem.

Even if an official white paper claims that

You do not need to develop your own provider if you are not going to share your data with other applications.

they added the possibility of having unexposed content providers using

 android:exported="false" 

All books read, including Reto Meier Professional Android Development 4, offer content providers.

In addition, at the cost of a lot of template code, you can forget about multithreading and problems with the open cursor.

In any case, I must say that the biggest advantage you get from the compiler of the content provider / cursor is that your loader is automatically notified of every change in the underlying data.

If you are using simple sqllite, you need to implement a way to receive client class notifications every time data changes in the background. For example, I used broadcast messages to notify of any activity that tables are updated inside intenservice.

Finally, I was a little disappointed with all the duplication of the code you are talking about, and I decided to write a python script to create a content provider in my place, using only the description of the data model. You will probably have to modify the generated class (or, better, extend it), but I think it saves a lot of time. You can find it here.

Conclusion

• if you want to export your data to other applications (not so often), you need to contact the content provider
• if you want to watch data / update ui because your dataset can be changed in the background, the content provider + downloader is extremely efficient
• if you have a preloaded dataset, and maybe you update it in the same action that displays the data, or you need to perform simple operations on your tables, perhaps the sqll helper class class is enough.