Android Content Provider Example Tutorial

android content provider example tutorial

Android Content Provider Example Tutorial

This post focuses on Android Content Provider Example Tutorial. Content providers deal with access to a prearranged set of data. They sum up the data, and make available mechanisms for defining data security. Content providers are the standard interface that links data in one process with code running in another process.

When you want to access data in a content provider, you make use of the ContentResolver object in your application’s Context to exchange a few words with the provider as a client.

The ContentResolver object communicates with the provider object, an instance of a class that implements ContentProvider. The provider object accepts data requests from clients, carries out the requested action, and provides the results.

You don’t require developing your own provider if you don’t have the intention of sharing your data with other applications. Nevertheless, you require your own provider to make available custom search suggestions in your own application.

You are as well required to have your own provider if you want to copy and paste complex data or files from your application to other applications.

Android itself includes content providers that manage data such as audio, video, images, and personal contact information. You can see some of them listed in the reference documentation for the android.provider package. With some restrictions, these providers are accessible to any Android application.

The following topics explain content providers in minute detail:

Content Provider Basics

This describes how to access data in a content provider when the data is structured in tables.

Fabricating a Content Provider

This describes the way you can create your own content provider.

Calendar Provider

This topic explains the way to access the Calendar Provider that is section of the Android platform.

Contacts Provider

This explains how to access the Contacts Provider that is a section of of the Android platform.

A content provider handles access to a core repository of data. You put into action a provider as one or more classes in an Android application, together with elements in the manifest file.

One of your classes implements a subclass ContentProvider, which is the interface between your provider and other applications.

Even though content providers are meant to make data accessible to other applications, you may of course have activities in your application that let the user question and alter the data supervised by your provider.

The remainder of this topic is a basic list of steps for building a content provider and a list of APIs to use.

What to consider before building

Before you begin creating a provider, you ought to do the following

Consider if you require a content provider

You are required to build a content provider if you want to make available one or more of the features below:

  • You want to make available complex data or files to other applications.
  • You want to permit users to copy composite data from your app into other apps.
  • You want to make available customized search suggestions with the use of the search framework.

You don’t require a provider to use a SQLite database if the use is completely within your own application.

  1. If you haven’t done that already, reading detailed information aboutContent Provider Basics will help you to learn more about providers. When you have got yourself acquainted with these basics, follow the steps below to build your provider:
  2. a) Create the raw storage for your data. A content provider provides data in two ways:

File data

File data is data that usually goes into files, like photos, audio, or videos. Store the files in your application’s secret space. In response to a request for a file from another application, your provider can provide a handle to the file.

Structured data

This is data that usually goes into a database, display, or similar configuration. Store the data in a structure that’s compatible with tables of rows and columns.

A row stands for an entity, like a person or an item in inventory. A column stands for a few data for the entity, like a person’s name or an item’s price.

A regular way to store this type of data is in an SQLite database, but you can make use of any type of unrelenting storage.

Define a concrete implementation of the ContentProvider class and its required methods. This class is the interface between your data and the remainder of the Android system.

  1. Describe the provider’s authority string, its content URIs, and column names. If you want the provider’s application to take care of intents, also describe intent actions, extras data, and flags. In addition describe the permissions that you will need for applications that intend to access your data. You ought to consider defining all of these values as constants in a different contract class; eventually, you can expose this class to other developers.
  2. Add other not obligatory pieces, like sample data or an implementation ofAbstractThreadedSyncAdapter that can harmonize data between the provider and cloud-based data.

Creating Data Storage

A content provider is the crossing point to data saved in a prearranged format. Before you design the interface, you ought to decide the way to store the data. You can store the data in any form you choose, and then create the interface to read and write the data as required.

These are a few data storage technologies that are accessible in Android:

  • The Android system consists of a SQLite database API that Android’s own providers use to store table-oriented data. TheSQLiteOpenHelper class assists you create databases, and the SQLiteDatabase class is the base class for accessing databases.

Remember that you don’t have to make use of a database to execute your repository. A provider appears outwardly as a set of tables, related to a relational database, but this is not a prerequisite for the provider’s internal implementation.

  • For storing file data, Android has a variety of file-oriented APIs. If you’re designing a provider that makes available media-related data like music or videos, you can have a provider that incorporates table data and files.
  • For working with network-based data, make use of classes innet and You can as well harmonize network-based data to a local data store like a database, and then provided the data as tables or files. The Sample Sync Adapter sample application illustrates this type of harmonization.

Data design considerations

Here are a number of tips for designing your provider’s data structure:

  • Table data ought to constantly possess a “primary key” column that the provider maintains an exclusive numeric value for each row. You can make use of this value to connect the row to related rows in other tables (using it as a “foreign key”).Even though you can make use of any name for this column, making use of_ID is the best alternative,for the fact that connecting the results of a provider question to a ListView needs one of the retrieved columns to have the name _ID.
  • If you intend to create bitmap images or other very large pieces of file-oriented data, store the data in a file and then make it accessible indirectly instead of storing it directly in a table. If you do this, you are supposed to tell users of your provider that they required making use of aContentResolver file technique to access the data.
  • Make use of the Binary Large OBject (BLOB) data type to store data that differs in size or has a differing structure. For instance, you can make use of a BLOB column to store aprotocol buffer or JSON structure.

You can as well make use of a BLOB to implement a schema-independent table. In this type of table, you define a principal key column, a MIME type column, and one or more general columns as BLOB.

The implication of the data in the BLOB columns is indicative of  the value in the MIME type column. This allows you to store different row types in the same table.

The Contacts Provider’s “data” table ContactsContract.Data is an example of a schema-independent table.

Designing Content URIs

Content URI is a URI that identifies data in a provider. Content URIs includes the figurative name of the whole provider (its authority) and a name that points to a table or file (a path).

The non obligatory id part points to an individual row in a table. Every data access method of ContentProvider has a content URI as an argument; this permits you to determine the table, row, or file to access.

Designing an authority

A provider normally has a single authority, which functions as its Android-internal name. To avoid conflicts with other providers, you ought to make use of Internet domain ownership (in reverse) as the source of your provider authority.

Due to the fact that this recommendation is as well true for Android package names, you can describe your provider authority as an extension of the name of the package that bears the provider.

For instance, if your Android package name is com.example.<appname>, you ought to give your provider the authority com.example.<appname>.provider.

Designing a path structure

Developers characteristically generate content URIs from the authority by attaching paths that point to individual tables.

For example, if you have two tables table1 and table2, you link the authority from the earlier example to produce the content URIs com.example.<appname>.provider/table1 and com.example.<appname>.provider/table2. Paths aren’t restricted to a single segment, and there doesn’t have to be a table for every level of the path.

Handling content URI IDs

As a principle, providers make available access to a single row in a table by accepting content URI with an ID value for the row at the end of the URI. Also by convention, providers match the ID value to the table’s _ID column, and perform the requested access against the row that matches.

This principle facilitates a regular design pattern for apps accessing a provider. The app does a query against the provider and shows the resulting Cursor in a ListView using a CursorAdapter. The definition of CursorAdapter needs one of the columns in the Cursor to be _ID

The user then picks one of the displayed rows from the UI in order to look at or adjust the data. The app gets the corresponding row from the Cursor backing the ListView, obtains the _ID value for this row, attaches it to the content URI, and sends the access appeal to the provider. The provider can then do the query or alteration against the exact row the user selected.

Content URI prototypes

To assist you select which action to take for an arriving content URI, the provider API incorporates the ease class UriMatcher, which charts content URI “prototypes” to integer values. You can make use of the integer values in a switch declaration that selects the preferred action for the content URI or URIs that go with a specific prototype.

A content URI prototype connects content URIs with the use of wildcard characters:

  • Matches a string of any valid characters of any length.
  • Matches a string of numeric characters of any length.

As an example of designing and coding content URI handling, think about a provider with the that identifies the following content URIs pointing to tables:

  • content:// A table known as table1.
  • content:// A table known as dataset1.
  • content:// A table known as dataset2.
  • content:// A table known astable3.

The provider as well identifies these content URIs if they have a row ID affixed to them, as for instance content:// for the row identified by 1 in table3.

The content URI patterns  below would be probable:


This goes with any content URI in the provider.


This goes with a content URI for the tables dataset1 and dataset2, but doesn’t go with content URIs for table1 or table3.


This goes with a content URI for single rows in table3, like content:// for the row recognized by 6.

Add a Comment