Android ContentProviders vs SQLite - android

If we want to share our data with other Android applications,
(1) we may create a SQlite database and make it accessible by other applications or
(2) create a ContentProvider.
What are the basic differences in the above mentioned two approaches?

ContentProvider is exposing data to other application, a non-content provider database is only accessible by that application.

Related

Why should I use a ContentProvider with exported=false?

I can't figure out why I should use a ContentProvider with the setting "android:exported=false" in the AndroidManifest.xml. Aren't ContentProviders created to share data between multiple applications? In this way, I am restricting data sharing only to my application and not to external applications. But at this point I can simply use a database in SQLite (maybe with SQLiteOpenHelper).
In the case where I need to create a pre-populated database by loading data from a Rest API, but at the same time I do not need to share my data to other applications, should I create a ContentProvider with the setting "android:exported=false" using the ContentProviderOperation and ContentProviderOperation.Builder Classes (I have seen that these two Classes are used for massive data insertion) ? Or should I create a database in SQLite and insert the data using the INSERT command ?
Thank you!

Can we use one database for two or more application

I am about to create two applications which have the same SQLite database. I went through this link. But it does not make sense. I have to update the database from both applications. Please suggest one or more better ways.
You should read about Content Provider
Content providers are one of the primary building blocks of Android
applications, providing content to applications. They encapsulate data
and provide it to applications through the single ContentResolver
interface. A content provider is only required if you need to share
data between multiple applications. For example, the contacts data is
used by multiple applications and must be stored in a content
provider. If you don't need to share data amongst multiple
applications you can use a database directly via SQLiteDatabase.
https://developer.android.com/guide/topics/providers/content-providers
https://developer.android.com/reference/android/content/ContentProvider
Content Provider is a great way to share database with other applications.
When you create a Content Provider, you can define which part of your database can be shared as well.
A Content Provider has following parts-
1. A class that extends ContentProvider class
2. An Authority that distinguishes this ContentProvider from others on the Android O.S.
3. A Contract class that holds Uri to tables and columns that you want to share with other applications
4. A ContentResolver to access data from a ContentProvider
5. Set of user defined permissions to write to and read from a shared ContentProvider. Permissions allow only those apps that you authorize to access your ContentProvider
Here is a simple tutorial about the use of ContentProvider and how to share your database with other applications- https://www.tutorialspoint.com/android/android_content_providers.htm

How is android.database different from android.database.sqlite?

I am trying to develop this android application whose database is not stored in the device but on a server. To use sqlite database I need to use android.database.sqlite; and I haven't made much use of android.database package. I went through the documentation site but it did not state clearly if it's possible can store my sqlite database file on server and invoke methods to access it from there. What should I do?
SQLite is not an ideal database to use on a server. The andriod.database.sqlite package is going to have resources for dealing with sqlite specifically, where the android.database package is going to have generic database resources, not specific to sqlite.
For using sqlite on a server, first bear in mind that concurrent connections are a big no-no... sqlite is not designed to handle them.
If I still felt I had to do this, I'd probably look at creating an adapter on the server which would accept requests from the application, then use the android.database.sqlite package on the server, as it's local per the scope there (as sqlite is designed for).
https://www.sqlite.org/serverless.html

ContentProvider usage

A content provider is only required if you need to share data between multiple applications.
Is this the only purpose of using it? What about simply getting data from the WS and writing it in the CP and then reading from here in Activities?
What about iosched:
CP is used here to share a database for several apps?
you just can achive that with a database, but I strong recommend the use of contentprovider even if you are not going to share data between aplications. classes such as CursorLoader (correction) load directly datas from contentprovider, if you use just a database you have to extend this class to get the same performance
so to conclude it's all made for working with contentprovider.

Android custom ContentProvider

Is it possible to create a custom ContentProvider to
Access android existing database (e.g. Contacts, SMS)?
Extend an Exciting ContentProvider which has access to android existing database (e.g. ContactsProvider to access Contacts DB)?
Thank you.
Short Answer: Yes
Longer answer:
ContentProviders are a layer sitting in between the "outside world" (e.g. other Android Activities) and the back-end data storage. You will never have direct access to the database. The database is stored in the Activities private storage space. So all you can do is dictated by the ContentProvider you are addressing.
If the ContentProvider only allows read-only access to the data, than that is all you can do.
So in the end, you can only offer access which has at most the kind of access as the ContentProvider you are using. You can however expose a different data structure. Or you could also create one ContentProvider which uses multiple other providers internally.
On the bottom line, within the given bounds, your imagination is the limit.

Categories

Resources