I see many people who start learning Android programming confuse between ContentProvider and ContentResolver. I hope I can clear some confusion (atleast not aggravate their confusions).
Content Provider is a class that extends ContentProvider. But conceptually, Content Provider is a class that provides data to other components of an Android application. But data can be sourced from many different places - web service, local SQLite database, or just an Array, or a combination of these. Every application developer designs their own data source based on their needs. Which means, each application developer should design and implement their own Content Provider that supports these four operations - insert(), query(), update(), delete(). If you are familiar with Design Patterns, this would fall under Strategy pattern.
So, someone wants to insert data, Content Provider executes insert() code which can probably call a HTTP POST in REST-based service. But, there is a caveat - Content Provider can be exposed across applications. For example, Contacts content provider is available to other Android application - you can get all contacts stored in the phone.
Imagine you are a developer of the components of an Android application other than the Content Provider. Since Content Provider is a class, we will somehow need to access the class for all CURD operations. If you are using a Content Provider from an different application (eg; Contacts) this is going to limit our development. Even more difficult would be to use Content Provider from third party.
Content Resolver helps solve these problems faced by the developers of Android components that use Content Provider. Each Content Provider is registered to a URL and exposed (to the same Android application or to other applications as well) through the Android Manifest. In Content Resolver, we pass the URI of the Content Provider along with the data (or query). Content Resolver gets the URI and resolves it to a specific Content Provider and invokes appropriate method (query(), insert(), update(), delete()).
Content Provider is a class that extends ContentProvider. But conceptually, Content Provider is a class that provides data to other components of an Android application. But data can be sourced from many different places - web service, local SQLite database, or just an Array, or a combination of these. Every application developer designs their own data source based on their needs. Which means, each application developer should design and implement their own Content Provider that supports these four operations - insert(), query(), update(), delete(). If you are familiar with Design Patterns, this would fall under Strategy pattern.
So, someone wants to insert data, Content Provider executes insert() code which can probably call a HTTP POST in REST-based service. But, there is a caveat - Content Provider can be exposed across applications. For example, Contacts content provider is available to other Android application - you can get all contacts stored in the phone.
Imagine you are a developer of the components of an Android application other than the Content Provider. Since Content Provider is a class, we will somehow need to access the class for all CURD operations. If you are using a Content Provider from an different application (eg; Contacts) this is going to limit our development. Even more difficult would be to use Content Provider from third party.
Content Resolver helps solve these problems faced by the developers of Android components that use Content Provider. Each Content Provider is registered to a URL and exposed (to the same Android application or to other applications as well) through the Android Manifest. In Content Resolver, we pass the URI of the Content Provider along with the data (or query). Content Resolver gets the URI and resolves it to a specific Content Provider and invokes appropriate method (query(), insert(), update(), delete()).
So, in short, Content Resolver resolves the URI to a particular Content Provider.
Content Provider actually performs the operation - in local SQLite db, some REST service, etc. - depending on the design.
This post is so usefull and informative.Keep updating with more information...
ReplyDeleteNeed Of Android
Android Platforms