requests • Servers process requests and return appropriate responses • Requests and responses are built around the transfer of representations of resources 3
uniform interface –Clients need not to worry about how data is stored on servers portable client code –Servers need not to worry about the user interface improves server scalability and makes servers simpler 4
ordinarily tell whether it is connected directly to the end server, or to an intermediary along the way –Hence allows for load balancing and shared caches 5
apps • Abstracting data into service • This idea of content providers makes data sources look like REST-enabled data providers such as web sites • A content provider is a wrapper around data • Content providers supply CRUD methods 7
device is an example of a data source that you can encapsulate into a content provider • Android also has several built-in content providers that encapsulate databases 8
in sharing data between applications • The content providers’ responsibility is to provide an encapsulation mechanism not a data-access mechanism • You’ll need an actual data access mechanism such as SQLite to get to the underlying data sources 9
Create a class that extends android.content.ContentProvider • Implement query(), insert(), update(), delete() • Register the ContentProvider authority in the manifest • Expose the URIs and schema 16
the exposed data (schema, URIs) • Set the appropriate permission(s) in the manifest, for built in: http://developer.android.com/reference/android/Manifest.permission.html • Get the URI(s) –Usually these are declared as a public constant inside the content provider class • Make a query(or other CRUD), maybe adding some where clauses –The query returns a Cursor • Navigate the Cursor 17
request permission via the manifest • Query the contacts content provider • Contacts information is shared among applications 18 <uses-permission android:name="android.permission.READ_CONTACTS"/>