Mark Murphy - Beginning Android

Building a content provider is probably the most complicated and tedious task in all of Android development. There are many requirements of a content provider, in terms of methods to implement and public data members to supply. And, until you try using it, you have no great way of telling if you did any of it correctly (versus, say, building an activity and getting validation errors from the resource compiler).

That being said, building a content provider is of huge importance if your application wishes to make data available to other applications. If your application is keeping its data solely to itself, you may be able to avoid creating a content provider, just accessing the data directly from your activities. But if you want your data to possibly be used by others — for example, if you are building a feed reader and you want other programs to be able to access the feeds you are downloading and caching — then a content provider is right for you.

As was discussed in the previous chapter, the content Uriis the linchpin behind accessing data inside a content provider. When using a content provider, all you really need to know is the provider’s base Uri; from there you can run queries as needed or construct a Urito a specific instance if you know the instance identifier.

When building a content provider, though, you need to know a bit more about the innards of the content Uri.

A content Urihas two to four pieces, depending on the situation:

• It always has a scheme ( content://), indicating it is a content Uriinstead of a Urito a Web resource ( http://).

• It always has an authority, which is the first path segment after the scheme. The authority is a unique string identifying the content provider that handles the content associated with this Uri.

• It may have a data type path, which is the list of path segments after the authority and before the instance identifier (if any). The data type path can be empty if the content provider handles only one type of content. It can be a single path segment ( foo) or a chain of path segments ( foo/bar/goo) as needed to handle whatever data-access scenarios the content provider requires.

• It may have an instance identifier, which is an integer identifying a specific piece of content. A content Uriwithout an instance identifier refers to the collection of content represented by the authority (and, where provided, the data path).

For example, a content Uricould be as simple as content://sekrits, which would refer to the collection of content held by whatever content provider was tied to the sekritsauthority (e.g., SecretsProvider). Or, it could be as complex as content://sekrits/card/pin/17, which would refer to a piece of content (identified as 17) managed by the sekritscontent provider that is of the data type card/pin.

Next you need to come up with some MIME types corresponding with the content from your content provider.

Android uses both the content Uri and the MIME type as ways to identify content on the device. A collection content Uri— or, more accurately, the combination authority and data type path — should map to a pair of MIME types. One MIME type will represent the collection; the other will represent an instance. These map to the Uripatterns discussed in the previous section for no-identifier and identifier cases, respectively. As you saw in Chapters 24 and 25, you can fill a MIME type into an Intentto route the Intentto the proper activity (e.g., ACTION_PICKon a collection MIME type to call up a selection activity to pick an instance out of that collection).

The collection MIME type should be of the form vnd.X.cursor.dir/Y, where Xis the name of your firm, organization, or project, and Yis a dot-delimited type name. So, for example, you might use vnd.tlagency.cursor.dir/sekrits.card.pinas the MIME type for your collection of secrets.

The instance MIME type should be of the form vnd.X.cursor.item/Y, usually for the same values of Xand Yas you used for the collection MIME type (though that is not strictly required).

Just as an activity and intent receiver are both Java classes, so is a content provider. So, the big step in creating a content provider is crafting its Java class, with a base class of ContentProvider.

In your subclass of ContentProvider, you are responsible for implementing six methods that, when combined, perform the services that a content provider is supposed to offer to activities wishing to create, read, update, or delete content.

As with an activity, the main entry point to a content provider is onCreate(). Here you can do whatever initialization you want. In particular, here is where you should lazy-initialize your data store. For example, if you plan on storing your data in such-and-so directory on an SD card, with an XML file serving as a “table of contents,” you should check if that directory and XML file are there and, if not, create them so the rest of your content provider knows they are out there and available for use.

Similarly, if you have rewritten your content provider sufficiently to cause the data store to shift structure, you should check to see what structure you have now and adjust it if what you have is out-of-date. You don’t write your own “installer” program and so have no great way of determining if, when onCreate()is called, this is the first time ever for the content provider, the first time for a new release of a content provider that was upgraded in place, or just a normal startup.

If your content provider uses SQLite for storage, you can detect if your tables exist by querying on the sqlite_mastertable. This is useful for lazy-creating a table your content provider will need.

For example, here is the onCreate()method for Provider, from the ContentProvider/Constantssample application available in the Source Code section of http://apress.com:

@Override

publicboolean onCreate() {

db = ( new DatabaseHelper( getContext())). getWritableDatabase();

return(db == null) ? false: true;

}

While that doesn’t seem all that special, the “magic” is in the private DatabaseHelperobject, described in the chapter on database access.

As one might expect, the query()method is where your content provider gets details on a query some activity wants to perform. It is up to you to actually process said query.

The query method gets the following as parameters:

• A Urirepresenting the collection or instance being queried

• A String[]representing the list of properties that should be returned

• A Stringrepresenting what amounts to a SQL WHEREclause, constraining which instances should be considered for the query results

• A String[]representing values to “pour into” the WHEREclause, replacing any ?found there