Public static final

If you are using SQLite as a data store, the values for the property name constants should be the corresponding column name in the table, so you can just pass the projection (array of properties) to SQLite on a , or pass the on an or .

Note that nothing in here stipulates the types of the properties. They could be strings, integers, or whatever. The biggest limitation is what a can provide access to via its property getters. The fact that there is nothing in code that enforces type safety means you should document the property types well so people attempting to use your content provider know what they can expect.

Step #4: Update the Manifest

The glue tying the content‑provider implementation to the rest of your application resides in your file. Simply add a provider element as a child of the element:

The property is the name of the content‑provider class, with a leading dot to indicate it is in the stock namespace for this application’s classes (just like you use with activities).

The property should be a semicolon‑delimited list of the authority values supported by the content provider. Recall, from earlier in this chapter, that each content is made up of a scheme, an authority, a data type path, and an instance identifier. Each authority from each value should be included in the list.

Now when Android encounters a content , it can sift through the providers registered through manifests to find a matching authority. That tells Android which application and class implements the content provider, and from there Android can bridge between the calling activity and the content provider being called.

Notify‑on‑Change Support

An optional feature your content provider offers its clients is notify‑on‑change support. This means that your content provider will let clients know if the data for a given content changes.

For example, suppose you have created a content provider that retrieves RSS and Atom feeds from the Internet based on the user’s feed subscriptions (via OPML, perhaps). The content provider offers read‑only access to the contents of the feeds, with an eye toward several applications on the phone using those feeds versus everyone implementing their own feed‑poll‑fetch‑and‑cache system. You have also implemented a service that will get updates to those feeds asynchronously, updating the underlying data store. Your content provider could alert applications using the feeds that such‑and‑so feed was updated, so applications using that specific feed could refresh and get the latest data.

On the content‑provider side, to do this call on your instance (available in your content provider via ). This takes two parameters: the Uri of the piece of content that changed, and the that initiated the change. In many cases, the latter will be ; a non‑ value simply means the observer that initiated the change will not be notified of its own changes.

On the content‑consumer side, an activity can call on its (via ). This ties a instance to a supplied Uri – the observer will be notified whenever is called for that specific . When the consumer is done with the , releases the connection.