Content Provider vs Direct Database Access (Transaction Management)

Question

I understand, at least on paper, the basic difference between the Content Provider and just directly accessing the SQLiteDatabase. I have a functioning prototype for my application, and currently it is just directly hitting the database. I don't really have any experience using the Content Provider pattern, but I have found out that I will need to share some data with another application.

I will only be sharing about 2 out of a dozen or so tables, so I was wondering if I should be just completely redoing the data layer to follow the Content Provider pattern, or just expose only those tables via a Content Provider for the sake of the other application and still directly access the database in the primary application.

One of the issues I ran into with my prototype was that I have some fairly complex transactions, and the code I wrote to get that working is not designed particularly well and isn't reusable at all. As I add more functionality to this app, I'm going to need a better designed data access layer, before I set off writing my own, does anyone know of any good resources with design patterns for this type of thing already? Also, if I need to go the Content Provider route, am I going to have solid control over the database transactions?

Answer 1

Don't quote me on this, but I'm pretty sure a content provider is a way to abstract the way you are providing data to an object. This way, your object can just communicate with the provider, and doesn't care about the implementation i.e. how/where the data is stored. Perhaps you might want to provide some other way to store your data in the future, and using the content provider paradigm will save you tons of rework, since it's just interface based communication.

I would use the Android design patterns everywhere I could. To be honest, looking at it now I really should be doing this in my project.

Answer 2

I don't think you should have a problem just making a content provider with the functionality you need that sits on top of your direct database code. A content provider is really just an abstraction for accessing structured data that happens to look very much like SQLite. :) If various internal parts of the app directly access the same database as the provider, as long as the code of the two plays together nicely, it should be fine.

I actually am not a fan of being absolute about "thou must always use content providers." If you don't need a content provider, don't use one; just do direct SQLite if it is easier. If you need a content provider for some specific interaction with other apps, feel free to write one just for that without making it a big complicated thing that supports all of the stuff your app does internally with the database. If this is easier, great. It also makes it much less likely for you unintentionally to expose private data from your app to others.