Menu
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?
519
In Android, Content Providers are a very important component that serves the purpose of a relational database to store the data of applications.
A content provider manages access to a central repository of data. A provider is part of an Android application, which often provides its own UI for working with the data. However, content providers are primarily intended to be used by other applications, which access the provider using a provider client object.
That is to say, a SQLite database created on Android by one application is usable only by that application, not by other applications. So, if you need to share data between applications, you need to use the content provider model as recommended in Android.
A content provider behaves very much like a database where you can query it, edit its content, as well as add or delete content using insert(), update(), delete(), and query() methods. In most cases this data is stored in an SQlite database.
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.
133
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
