I've more than one activity (inside the same Application) that needs to have access to the database. What's the best pattern to implement this ? Do I need a content provider even if all activities belong to the same application?
Which activity should have the responsibility for opening and closing the database ?
Your two options are Content Provider or just using your own database abstraction layer. The content provider is a better way to go as pointed out, if you need other apps to share your data or if you need to hook into some other part of Android (like the Quick Search framework). It should not be tied into an Activity - should just be a separate class that you import and use.
The OReilly Android programming book has a chapter which illustrates both approaches, its a good read.
Not necessary. You just have to create a Content Provider if you want some external application to access your data.
Content providers offer a structured storage mechanism that can be limited to your own application or exported to allow access by other applications. If you do not intend to provide other applications with access to your ContentProvider, mark them as android:exported=false in the application manifest. Otherwise, set the android:exported attribute to true to allow other apps to access the stored data.
https://developer.android.com/training/articles/security-tips
Related
i'm beginner in android development, need help regarding ContentProvider.
public class My Application extends ContentProvider {}
A ContentProvider manages access to a structured set of data. It encapsulates the data and provide mechanisms for defining data security. ContentProvider is the standard interface that connects data in one process with code running in another process.
Kindly refer following links,
https://developer.android.com/guide/topics/providers/content-provider-creating.html
and
https://www.tutorialspoint.com/android/android_content_providers.htm
A content provider component supplies data from one application to others on request. one application cannot directly access (read/write) other application's data. Every application has its own id data directory and own protected memory area.
Content provider is the best way to share data across applications. Content provider is a set of data wrapped up in a custom API to read and write. Applications/Processes have to register themselves as a provider of data.
In simple language you can say content provider is a shared database which expose his properties and on there behalf of them other application can access and store the data as per the implementation privilege
Content providers can help an application manage access to data stored by itself, stored by other apps, and provide a way to share data with other apps. They encapsulate the data, and provide mechanisms for defining data security. Content providers are the standard interface that connects data in one process with code running in another process. Implementing a content provider has many advantages. Most importantly you can configure a content provider to allow other applications to securely access and modify your app data.
It is not that they are used only to share data with other applications. You may still use them because they provide a nice abstraction, but you don’t have to necessarily share data with other apps. This abstraction allows you to make modifications to your application data storage implementation without affecting other existing applications that rely on access to your data
You can get more info from the documentation.
ContentProvider is mainly used for access data from one application to another application.
For example by using ContentProvider we can get phone contacts,call log from phone to our own application in android.we can also access data which are stored in (sqlite)databases.
I'm hoping someone smarter then me can answer this question.
By default can all android databases be accessed through the ContentProvider, or does the application in question have to explicitly give permissions to share it with the CP before another program can access its db?
If they are not shared by default, short of getting the application developer to include the change, root would be the only way around it?
By default can all android databases be accessed through the ContentProvider, or does the application in question have to explicitly give permissions to share it with the CP before another program can access its db?
By default, a ContentProvider is exported, meaning third parties can perform CRUD operations upon it. You can change this behavior either by:
Marking it as not exported (android:exported="false" on the <provider> element)
Using your own custom permissions to allow the user to conditionally allow access to the provider
If they are not shared by default, short of getting the application developer to include the change, root would be the only way around it?
Root will not help you access another applications' content provider. Please respect the wishes of the other developer.
dear i am confused the use of content provider in android applications.i go through various sides and read it but i am still confused about content provider ..can any one explain it in some simple way ,how to use it?
Content providers store and retrieve data and make it accessible to all applications....whats that means?
can it means any package name or in same pakage name...
if i am making another app of diffrent package name then that c.p. is available also in that package?
OK, first of all, a content provider will be used if and only if you want to use the same data through several applications. You can still use it if you want to implement it in your application.
Now, by definition a ContentProvider "Content providers manage access to a structured set of data. They encapsulate the data, and provide mechanisms for defining data security." (According to Android Developer Guides)
So in other words, it's like a new layer of abstraction that you are adding to your data, assigning a new man-in-the-middle that will request everything you ask it to do (read, write, update your database, files, or webservices). And this man-in-the-middle is not only available for you, it's also available for other apps if you set the tag android:exported to true in the <provider> in your manifest file.
A ContentProvider needs you to implement:
A contract: Basically a class with public static variables with your tables names and the fields of info for those tables.
A data model: Normally a database in SQLite but you can implement it also with third party libraries like SugarORM, GreenDao, Retrofit, local files, etc).
Your custom ContentProvider: Extend ContentProvider and inside here set the calls to your data model.
This is a good tutorial on how to make your own ContentProvider:
http://www.grokkingandroid.com/android-tutorial-writing-your-own-content-provider/
There are also a few libraries that will help you create a ContentProvider automatically (I find it amazing because it takes you like 10 min to set up everything, instead of creating your own ContentProvider from scratch which could take you days).
My personal favorite is Schematic:
https://github.com/SimonVT/schematic
I hope it helps. Kind regards!
how to use it?
you actually don't use it directly, but via the content resolver (which will, according to the URI you give it, query the right ContentProvider) :
getContentResolver().query("content://com.myapp.myprovider/data/", ...);
will find your content provider if that one is registered to handle URIs that match "content://com.myapp.myprovider/data/"
if i am making another app of diffrent
package name then that c.p. is
available also in that package?
If you decide to publish the content provider, it is available outside of your application (this is a setting in the manifest).
what is the major benifit of using c.p.?
It is a common design pattern in Android to offer access to data. Major benefit is that you can abstract access to your data and decide whether to open it to other applications or not. For instance, without content providers, you could not access the media stored on the phone or the contacts of the phone.
Since a package is meant as a unique identifier for an application, how can you create an app with the same package name? If this was your question, I think I've answered it. If you don't understand something else - feel free to ask. Good luck!
P.S. Consider accepting some answers, your accept ratio is low.
Q-1 - To create my own Content Provider class, when I should extend ContentProvider class and when I should not extend ContentProvider class ?
Q-2 - If I create Content Provider without CONTENT_URI(like many other built-in content providers in android.provider.*, how will I use managedQuery(...) or query(....).
I have seen response to similar question in this question on content provider but I am not sure they answer it completly.
1) Even with extension you'd be implementing the methods anyway. A ContentProvider allows you to actually use the internal system for Android to access data from different places in your application. Basically, if you are storing data, extend the ContentProvider and use either ContentResolver.query or Activity.managedQuery to access that data.
2) AFAIK (and this could be wrong), you need a CONTENT_URI when you create a ContentProvider. This is how the ContentResolver knows where it should be pulling from and one way to allow your application to even access that data (through the application manifest). So, use a CONTENT_URI. There isn't much of a reason not to IMO.
I understand that Content Providers are made to allow publicly sharing data between applications. However, I'm wondering if anyone has thoughts about making a Content Provider to use just within your own app. Would there be any advantages to doing this? Any disadvantages?
In the past I've just implemented the SQliteOpenHelper to access data from my database, but I'm considering creating a Content Provider. I feel like the URI approach to requesting data is clear and concise. On the other hand, will using a Content Provider just for my application be redundant ( since within it I will have a SQliteOpenHelper class ) and more work than I need?
I would argue it is definitely a good idea to use a ContentProvider even if you don't intend to make it public.
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.
Also, there is always the chance that you might want to expose your data in the future. If you don't use a ContentProvider up front, it will be much harder to retrofit it in at a later date.
Then, there's the other parts of the Android where ContentProvider's are required/recommended such as when using SyncAdapters and if you want an App Widget that involves data access for instance.
In summary, there is very little overhead involved in writing a ContentProvider up front (once you have learned the API which is a good idea anyway) so it makes sense to do so, even for private data.
If you are not planning to share data, don't think about Content Providers. They are powerful but hard to write and it will be just silly to implement them if you are going to use them internally.
However, I'm wondering if anyone has thoughts about making a Content Provider to use just within your own app.
Of course... for instance, for an old TODO list app I wrote, I had to write a content provider to allow other apps retrieve and access the tasks states. It was part of the requirements, but more than that it made sense and made the app nicer.
Take a look at the MOTODEV Studio for Eclipse. It is a development environment that extends Eclipse. They have a tool where you can automatically generate a content provider for a database. If a content provider makes it easier to access your data and it doesn't have a significant impact on performance go ahead and use it. In most scenarios this will be the case.
In short,Content Providers helps in managing your data effectively. I would suggest to use them for the following reasons.
It acts as an abstraction layer between your UI and database. You can implement data validation in ContentProviders to validate the data entered by the user. It also lets you to modify the structure of the database without touching the UI and other parts.
They play along nicely with other android framework classes like SyncAdapter. For eg., you can automatically refresh a list, when a value in a database changes using ContentProviders along with CursorLoader. Without ContentProviders you have to implement a lot of functionalities like these on your own.
We can safely expose our private data to other apps. Using ContentProviders will allow us to share our data easily and safely with other apps.
So even if you don't need any of these functionalities now, you might need them in future and its good to go the extra mile and implement them right now.
I agree ContentProviders are a little difficult to grasp but they are definitely helpful, even if you want to use them internally for you own app. The best thing about it is that you can customize the contentproviders for suitable URIs.
Here's a scenario where you may have 5 tables in your database, but you need to join a few of them in certain orders before using them. And make a content URI for each of these joins. You could then each use these URIs as a table :)
I suggest you go ahead with Content Provider, you'll be amazed to see how powerful it is.
In my view point, the content-provider comes with plenty of advantages leave alone just sharing data with other apps. If you need to synchronize with the server using a Sync-Adapter, use google cloud messaging, auto update the UI when the underlying data in the DB changes using Loaders, implement search, use widgets... then the content provider is for you.
I prefer you follow the guideline on because one day you may need to implement some of the above features attached to the content-provider
By the way, you can quickly build you database and CP in less than 5 minutes using content provider generator
As said in documentation:
Creating a Content provider
You don't need a provider to use an SQLite database if the use is
entirely within your own application.
So why bother developing this overhead? You want easier and faster development, right? So one layer of abstraction (SQLiteOpenHelper descendent) is enough.
See Occam's Razor
Do not make an entities without very good reason.
Using a Content Provider can help in an additional level of abstraction - Putting it within your own application make add a significant development time to your project. However if you are using it to share data, application settings or configurations across multiple applications then the Content Provider is your choice.
Watch your security levels and I would recommend using SQLcipher to encrypt data-at-reset (DAR) if your Content Provider is writing to SQLite. (I've used a content provider in a few solutions and provided the ability to take a live "snap shot" of the operational values for debugging and testing.)
Do not use content provider if do not wish to share data with other apps. Use simple sqlitedatabase to perform database operations. Be careful while using content providers for storing confidential data because your confidential information may be accessed by other apps