what are the advantages of using a ContentProvider over normal SQLIte storage?

Question

I want to share data across multiple applications, instead of having a ContentResolver->ContentProvider mechanism, I can just define a client library which talks to the process which does the SQLite DB operations right?

What does the ContentProvider brings in here which we cannot achieve by having a Process expose the data?

Answer 1

You can find answer Exact Difference between “Content-Provider” and “SQLite Database”.

But I like to explain this..

What does the ContentProvider brings in here which we cannot achieve by have a Process expose the data?

There is one particular SQLite limitation you should be aware of and that is that SQLite is single-user only. What this really means is that you will need to guard your database from being accessed from multiple threads at the same time. This is generally not a problem in a content provider, since they almost always have a single-threaded implementation.

Also It's good practice to provide the extra level of abstraction over your data to make it easier to change internally. What if you decide to change the underlying database structure at a later time? If you use a ContentProvider you can contain all the structural changes within it, where as if you don't use one, you are forced to change all areas of the code that are affected by the structural changes. Besides, it's nice to be able to re-use the same standard API for accessing data rather than littering your code with low-level access to the database.