File reading and writing operations are done using standard Java methods. Check out the subclasses of java.io.InputStream for reading bytes from different types of primitive file types. For example, DataInputStream is useful for reading one line at a time.

Here’s a simple example of how to read a text file, line by line, and store it in a StringBuffer:

The Android SDK includes several utilities for working with XML files, including SAX, an XML Pull Parser, and limited DOM, Level 2 Core support. The packages helpful for XML parsing on the Android platform are listed in Table 9.4.

The simplest way to create a new SQLiteDatabase instance for your application is to use the openOrCreateDatabase() method of your application Context, like this:

Android applications store their databases (SQLite or otherwise) under in a special application directory:

So, in this case, the path to the database would be

You can access your database using the sqlite3 command-line interface using this path.

Now that you have a valid SQLiteDatabase instance, it’s time to configure it. Some important database configuration options include version, locale, and the thread-safe locking feature.

Creating tables and other SQLite schema objects is as simple as forming proper SQLite statements and executing them. The following is a valid CREATE TABLE SQL statement. This statement creates a table called tbl_authors. The table has three fields: a unique id number, which auto-increments with each record and acts as our primary key, and firstname and lastname text fields.

This CREATE TABLE SQL statement can be encapsulated in a static final String variable (called CREATE_AUTHOR_TABLE) and then executed on our database using the execSQL() method:

The execSQL() method works for nonqueries. You can use it to execute any valid SQLite SQL statement. For example, you can use it to create, update, and delete tables, views, triggers, and other common SQL objects. In our application, we add another table called tbl_books. The schema for tbl_books looks like this:

Unfortunately, SQLite does not enforce foreign key constraints. Instead, we must enforce them ourselves using custom SQL triggers. So we create triggers, such as this one that enforces that books have valid authors:

We can then create the trigger simply by executing the CREATE TRIGGER SQL statement:

We need to add several more triggers to help enforce our link between the author and book tables, one for updating tbl_books and one for deleting records from tbl_authors.

We use the insert() method to add new data to our tables. We use the ContentValues object to pair the column names to the column values for the record we want to insert. For example, here we insert a record into tbl_authors for J.K Rowling.

The insert() method returns the id of the newly created record. We use this author id to create book records for this author.

You might want to create simple classes (that is, class Author and class Book) to encapsulate your application record data when it is used programmatically. Notice that we did this in the FullDatabase sample project.

You can modify records in the database using the update() method. The update() method takes four arguments:

Passing null to the WHERE clause modifies all records within the table. This can be useful for making sweeping changes to your database.

Most of the time, we want to modify individual records by their unique identifier. The following function takes two parameters: an updated book title and a bookId. We find the record in the table called tbl_books corresponding with the id and update that book’s title. Again, we use the ContentValues object to bind our column names to our data values:

Because we are not updating the other fields, we do not need to include them in the ContentValues object. We include only the title field because it is the only field we change.

You can remove records from the database using the remove() method. The remove() method takes three arguments:

Passing null to the WHERE clause deletes all records within the table. For example, this function call deletes all records within the table called tbl_authors:

Most of the time, though, we want to delete individual records by their unique identifier. The following function takes a parameter bookId and deletes the record corresponding to that unique id (primary key) within the table called tbl_books.

You need not use the primary key (id) to delete records. The WHERE clause is entirely up to you. For instance, the following function deletes all book records in the table tbl_books for a given author by the author’s unique id.

Often you have multiple database operations you want to happen all together or not at all. You can use SQL Transactions to group operations together; if any of the operations fails, you can handle the error and either recover or rollback all operations. If the operations all succeed, you can then commit them. Here we have the basic structure for a transaction:

Now let’s look at the transaction in a bit more detail. A transaction always begins with a call to beginTransaction() method and a try/catch block. If your operations are successful, you can commit your changes with a call to the setTransactionSuccessful() method. If you do not call this method, all your operations will be rolled back and not committed. Finally, you end your transaction by calling endTransaction(). It’s as simple as that.

In some cases, you might recover from an exception and continue with the transaction. For example, if you have an exception for a read-only database, you can open the database and retry your operations.

Finally, note that transactions can be nested, while the outer transaction either committing or rolling back all inner transactions.

When results are returned from a SQL query, they are often accessed using a Cursor found in the android.database.Cursor class. Cursor objects are rather like file pointers; they allow random access to query results.

You can think of query results as a table, in which each row corresponds to a returned record. The Cursor object includes helpful methods for determining how many results were returned by the query and the column names (fields) for each returned record. The columns in the query results are defined by the query, not necessarily by the database columns. These might include calculated columns, column aliases, and composite columns.

Cursor objects are generally kept around for a time. If you do something simple (such as get a count of records or when you know you retrieved only a single simple record), you can execute your query and quickly extract what you need; don’t forget to close the Cursor when you’re done, as shown here:

Iterating Rows of Query Results and Extracting Specific Data

You can use the Cursor to iterate those results, one row at a time using various navigation methods such as moveToFirst(), moveToNext(), and isAfterLast().

On a specific row, you can use the Cursor to extract the data for a given column in the query results. Because SQLite is not strongly typed, you can always pull fields out as Strings using the getString() method, but you can also use the type-appropriate extraction utility function to enforce type safety in your application.

For example, the following method takes a valid Cursor object, prints the number of returned results, and then prints some column information (name and number of columns). Next, it iterates through the query results, printing each record.

The output to the LogCat for this function might look something like Figure 9.1.

Figure 9.1. Sample log output for the logCursorInfo() method.

Your first stop for database queries should be the query() methods available in the SQLiteDatabase class. This method queries the database and returns any results as in a Cursor object.

The query() method we mainly use takes the following parameters:

Previously in the chapter, we called the query() method with only one parameter set the table name.

This is equivalent to the SQL query:

So let’s add a WHERE clause to our query, so we can retrieve one record at a time.

This is equivalent to the SQL query:

Selecting all results might be fine for tiny databases, but it is not terribly efficient. You should always tailor your SQL queries to return only the results you require with no extraneous information included. Use the powerful language of SQL to do the heavy lifting for you whenever possible, instead of programmatically processing results yourself. For example, if you need only the titles of each book in the book table, you might use the following call to the query() method:

This is equivalent to the SQL query:

As your queries get more complex and involve multiple tables, you want to leverage the SQLiteQueryBuilder convenience class, which can build complex queries programmatically.

When more than one table is involved, you need to make sure you refer to columns within a table by their fully qualified names. For example, the title column within the tbl_books table would be tbl_books.title. Here we use a SQLiteQueryBuilder to build and execute a simple INNER JOIN between two tables to get a list of books with their authors:

First, we instantiate a new SQLiteQueryBuilder object. Then we can set the tables involved as part of our JOIN and the WHERE clause that determines how the JOIN occurs. Then, we call the query() method of the SQLiteQueryBuilder that is similar to the query() method we have been using, except we supply the SQLiteDatabase instance instead of the table name. The above query built by the SQLiteQueryBuilder is equivalent to the SQL query:

All these helpful Android query utilities can sometimes make building and performing a nonstandard or complex query too verbose. In this case, you might want to consider the rawQuery() method. The rawQuery() method simply takes a SQL statement String (with optional selection arguments if you include ?s) and returns a Cursor of results. If you know your SQL and you don’t want to bother learning the ins and outs of all the different SQL query building utilities, this is the method for you.

For example, let’s say we have a UNION query. These types of queries are feasible with the QueryBuilder, but their implementation is cumbersome when you start using column aliases and the like.

Let’s say we want to execute the following SQL UNION query, which returns a list of all book titles and authors whose name contains the substring ow (that is Hallows, Rowling), as in the following:

We can easily execute this by making a string that looks much like the original query and executing the rawQuery() method.

We make the substrings (ow) into selection arguments, so we can use this same code to look for other substrings searches).

Deleting tables and other SQLite objects is done in exactly the same was as creating them. Format the appropriate SQLite statements and execute them. For example, to drop our tables and triggers, we can execute three SQL statements:

You should close your database when you are not using it. You can close the database using the close() method of your SQLiteDatabase instance, like this:

The simplest way to delete a SQLiteDatabase is to use the deleteDatabase() method of your application Context. Databases are deleted by name and the deletion is permanent. All data and schema information is lost.

You’ve probably realized by now that it is time to start organizing your database fields programmatically to avoid typos and such in your SQL queries. One easy way to do this is to make a class to encapsulate your database schema in a class, such as PetDatabase, shown here:

By implementing the BaseColumns interface, we begin to set up the underpinnings for using database-friendly user interface widgets in the future, which often require a specially named column called _id to function properly. We rely on this column as our primary key.

To extend the SQLiteOpenHelper class, we must implement several important methods, which help manage the database versioning. The methods to override are onCreate(), onUpgrade(), and onOpen(). We use our newly defined PetDatabase class to generate appropriate SQL statements, as shown here:

Now we can create a member variable for our database like this:

Now, whenever our application needs to interact with its database, we request a valid database object. We can request a read-only database or a database that we can also write to. We can also close the database. For example, here we get a database we can write data to:

If you peruse the PetTracker application provided on the CD, you notice that its functionality includes no magical data-binding features, yet the application clearly uses the database as part of the user interface.

Specifically, the database is leveraged

• When you save new records using the Pet Entry Form (Figure 9.2, left).

Figure 9.2. The PetTracker application: Entry Screen (left, middle) and Pet Listing Screen (right).

• When you fill out the Pet Type field, the AutoComplete feature is seeded with pet types already in listed in the table_pettypes table (Figure 9.2, middle).

• When you display the Pet List screen, we query for all pets and use a Cursor to programmatically build a TableLayout on-the-fly (Figure 9.2, right).

This might work for small amounts of data; however, there are various drawbacks to this method. For example, all the work is done on the main thread, so the more records you add, the slower your application response time becomes. Second, there’s quite a bit of custom code involved here to map the database results to the individual user interface components. If you decided you want to use a different widget to display your data, you would have quite a lot of rework to do. Third, we constantly requery the database for fresh results, and we might be requerying far more than necessary.

Ideally, you’d like to bind your data to user interface widgets and let them take care of the data display. For example, we can use a fancy ListView to display the pets instead of building a TableLayout from scratch. We can spin through our Cursor and generate ListView child items manually, or even better, we can simply create a data adapter to map the Cursor results to each TextView child within the ListView.

We included a project called “SuperPetTracker” on the CD accompanying this book (also available on the book Web site) that does this. It behaves much like the “PetTracker” sample application, except that it uses the SimpleCursorAdapter with ListView and an ArrayAdapter to handle AutoCompleteTextView features.

Binding Data Using SimpleCursorAdapter

Let’s now look at how we can create a data adapter to mimic our Pet Listing screen, with each pet’s name and species listed. We also want to continue to have the ability to delete records from the list.

As you remember from Chapter 7, “Designing Android User Interfaces with Layouts,” the ListView container widget can contain children such as TextView objects. In this case, we want to display each Pet’s name and type. We therefore create a layout file called pet_item.xml which becomes our ListView item template:

And in our main layout file for the Pet List, we place our ListView in the appropriate place on the overall screen. The ListView portion of the layout file might look something like this:

Now to programmatically fill our ListView, we must take the following steps:

1. Perform our query and return a valid Cursor (a member variable).
2. Create a data adapter that maps the Cursor columns to the appropriate TextView widgets within our pet_item.xml layout template.
3. Attach the adapter to the ListView.

In the following code, we perform these steps.

Notice that the _id column as well as the expected name and type columns appears in the query. This is required for the adapter and ListView to work properly.

Using a ListView (Figure 9.3, left) instead of a custom user interface allows us to take advantage of the ListView widget’s built-in features, such as scrolling when the list becomes longer, and the ability to provide context menus as needed. The _id column is used as the unique identifier for each ListView child node. If we choose a specific item on the list, we can act on it using this identifier, for example, to delete the item.

Figure 9.3. The SuperPetTracker application: Pet Listing Screen ListView (left) with Delete feature (right).

Now we reimplement the Delete functionality by listening for onItemClick() events and providing a Delete Confirmation dialog (Figure 9.3, right).

You can see what this would look like on the screen in Figure 9.3.

Note that within the SuperPetTracker sample application, we also use an ArrayAdapter to bind the data in the pet_types table to the AutoCompleteTextView on the Pet Entry screen. Although our next example shows you how to do this in a preferred manner, we left this code in the PetTracker sample to show you that you can always intercept the data your Cursor provides and do what you want with it. In this case, we create a String Array for the AutoText options by hand. We use a built-in Android layout resource called android.R.layout.simple_dropdown_item_1line to specify what each individual item within the AutoText listing will look like. You can find the built-in layout resources provided within your Android SDK directory under the directory toolslib esdefaultlayout.

Most access to content providers comes in the form of queries: a list of contacts, a list of bookmarks, a list of calls, a list of pictures, and a list of audio files. Applications make these requests much as they would access a database, and they get the same type of structured results. The results of a query are often iterated through using a cursor. However, instead of crafting queries, we use URIs.

You can think of a URI as an “address” to the location where content exists. URI addresses are hierarchical. Most content providers, such as the Contacts and the MediaStore, have predefined URI addresses defined. For example, to access the External Media Device (a.k.a the SD card), we use the following URI:

We can query the Media Store content provider using the URI much like we would query a database. We now use the managedQuery() method to return a managed Cursor containing all media available on the SD card.

Now we have retrieved the records for each piece of media available on the SD card.

Now we have this Cursor, but we still have some legwork to get our Gallery widget to display the individual images.

We need to extend the BaseAdapter class for a new type of data adapter called ImageUriAdapter to map the URI data we retrieved to the Gallery widget. Our custom ImageUriAdapter maps the Cursor results to an array of GalleryRecord objects, which correspond to the child items within the Gallery widget. Although the code for the ImageUriAdapter is too long to show here, we go over some of the methods you must implement for the adapter to work properly.

After all this magic has been implemented, we can set our newly defined custom adapter to the adapter used by the Gallery with our new Cursor.

Notice that we added two new columns to our SQLite database: the base URI for the image and the individual image id, which is the unique identifier tacked to the end of the URI. We do not save the image itself in the database, only the URI information to retrieve it.

When the user presses the Save button on the Pet Entry screen, we examine the Gallery item selected and extract the information we require from the Tag property of the selected View, like this:

We can then save our Pet Record as we have before.

Now that our Pet Entry form is saved properly, we must turn our attention to the Pet Listing screen. Our ListView is getting more complicated; each item needs to contain an ImageView and two TextView widgets for the pet name and species. We begin by defining a custom layout template for each ListView item called pet_item.xml. This should be familiar; it contains an ImageView and two TextView objects.

We want to make sure this implementation is scalable, in case we want to add new features to individual ListView items in the future. So instead of taking shortcuts and using standard adapters and built-in Android layout templates, we implement another custom adapter called PetListAdapter.

The PetListAdapter is similar to the ImageUriAdapter we previously implemented for the Gallery widget. Only this time, instead of Gallery child items, we work with the ListView child records, which correspond to each pet. Again, the constructor maps the Cursor data to an array of PetRecord objects.

The getView() method of the PetListAdapter is where the magic occurs. Here we use a LayoutInflater to inflate our custom layout file called pet_item.xml for each ListView item. Again we use the Tag property of the view to store any information about the record that we might use later. It is here that we use the URI information we stored in our database to rebuild the fully qualified image URI using the Uri.parse() and ContentUris.withAppendedId() utility methods and assign this URI to the ImageView widget using the setImageURI() method.

Now that we’ve set everything up, we then assign the PetListAdapter to our ListView:

That’s about it. Note that you can also create the ListView item layout programmatically (see the PetListItemView class and the PetListAdapter.getView() method comments for more information).

Now you’ve seen how to leverage a content provider to make your application more robust, but this example has scratched only the surface of how powerful Content Providers can be. Let’s look at some of the other Content Providers available on the Android platform and what you can do with them.

Let’s start with the MediaStore Content Provider because we’ve already begun to explore it in the preceding MediaPetTracker sample application. You can use the MediaStore Content Provider to access media on the phone and on external storage devices. The primary types of media that can be accessed are audio, images, and video. These different types of media can be accessed through their respective Content Provider classes under android.provider.MediaStore.

Most of the MediaStore classes allow full interaction with the data. You can retrieve, add, and delete media files from the device. There are also a handful of helper classes that define the most common data columns that can be requested.

Some commonly used classes are found under android.provider.MediaStore, as shown in Table 9.6.

The following code demonstrates how to request data from a content provider. A query is made to the MediaStore to retrieve the titles of all the audio files on the SD card of the handset and their respective durations. This code requires that you load some audio files onto the virtual SD card in the emulator, much as we added image files in the MediaPetTracker sample application.

The MediaStore.Audio.Media class has predefined strings for every data field (or column) exposed by the content provider. You can limit the audio file data fields requested as part of the query by defining a string array with the column names required. In this case, we limit the results to only the track title and the duration of each audio file.

We then use a managedQuery() method call. The first parameter is the predefined URI of the content provider you want to query (in this case, the SD card). The second parameter is the list of columns to return (audio file titles and durations). The third and fourth parameters control any selection filtering arguments, and the fifth parameter provides a sort method for the results. We leave these null, as we want all audio files at this location. By using the managedQuery() method, we get a managed Cursor as a result. We then examine our Cursor for the results.

Android provides a Content Provider to access the call log on the handset via the class android.provider.CallLog. At first glance, the CallLog might not seem to be a useful provider for developers, but it has some nifty features. You can use the CallLog to filter recently dialed calls, received, and missed calls. The date and duration of each call is logged and tied back to the Contact application for caller identification purposes.

The CallLog is a useful Content Provider for customer relationship management (CRM) applications. The user can also tag specific phone numbers with custom labels within the Contact application.

To demonstrate how the CallLog Content Provider works, let’s look at a hypothetical situation where we want to generate a report of all calls to a number with the custom labeled HourlyClient123. Android allows for custom labels on these numbers, which we leverage for this example:

This code is similar to the code shown for the MediaStore audio files. Again, we start with listing our requested columns: the call label and the duration of the call. This time, however, we don’t want to get every call in the log, only those with a label of HourlyClient123. To filter the results of the query to this specific label, it is necessary to specify the third and fourth parameters of the managedQuery() call. Together, these two parameters are equivalent to a database WHERE clause. The third parameter specifies the format of the WHERE clause with the column name with selection parameters (shown as ?s) for each selection argument value. The fourth parameter, the String array, provides the values to substitute for each of the selection arguments (?s) in order as you would do for a simple SQLite database query.

As before, the Activity manages the Cursor object lifecycle. We use the same method to iterate the records of the Cursor and add up all the call durations.

Another useful, built-in content provider is the Browser. The Browser Content Provider exposes the user’s browser site history and their bookmarked Web sites. This Content Provider is accessed via the android.provider.Browser class. As with the CallLog class, the information provided by the Browser Content Provider can be used to generate statistics and to provide cross-application functionality. You might use the Browser Content Provider to add a bookmark for your application support Web site.

In this example, we query the Browser Content Provider to find the top five most frequently visited bookmarked sites.

Again, the requested columns are defined, the query is made, and the cursor iterates through the results.

Note that the managedQuery() call has become substantially more complex. Let’s take a look at the parameters to this method in more detail. The first parameter, Browser.BOOKMARKS_URI, is a URI for all browser history, not only the Bookmarked items. The second parameter is still the requested columns for the query results. The third parameter specifies the bookmark property must be true. This is a column needed to filter on it in the query. Now the results will only be browser history entries that have been bookmarked. The fourth parameter, selection arguments, is used only when replacement values are used, which is not used in this case, so the value is set to null. Lastly, the fifth parameter specifies an order to the results (most visited in descending order).

The Contacts database is one of the most commonly used applications on the mobile phone. People always want phone numbers handy for calling friends, family, coworkers, and clients. Additionally, most phones show the identity of the caller based on the contacts application, including nicknames, photos, or icons.

Android provides a built-in Contact application, and the contact data is exposed to other Android applications using the Content Provider interface. As an application developer, this means you can leverage the user’s contact data within your application for a more robust user experience.

Another useful Content Provider is the UserDictionary provider, which was introduced in Android 1.5. This Content Provider can be used for predictive text input on text fields and other user input mechanisms. Individual words stored in the dictionary are weighted by frequency and organized by locale. You can use the addWord() method within the UserDictionary.Words class to add words to the custom user dictionary.

Using the Contacts Content Provider, we can, for example, add a new record to the contacts database programmatically.

Just as we used the ContentValues class to insert records into an application’s SQLite database, we use it again here. The first action we take is to provide a name for the Contacts.People.Name column. We need to create the contact with a name before we can assign information, such as phone numbers. Think of this as creating a row in a table that provides a one-to-many relationship to a phone number table.

Next, we insert the data in to the database found at the Contacts.People.CONTENT_URI path. We use a call to getContentResolver() to retrieve the ContentResolver associated with our Activity. The return value is the Uri of our new contact. We need to use it for adding phone numbers to our new contact. We then reuse the ContentValues instance by clearing it and adding a Contacts.Phones.NUMBER and the Contacts.Phones.TYPE for it. Using the ContentResolver, we insert this data into the new Uri created.

Inserting data isn’t the only change you can make. One or more rows can be updated, as well. This following block of code shows how to update data within a Content Provider. In this case, we’re updating a note field for a specific contact, using its unique identifier.

Again, we use an instance of the ContentValues object to map the data field we want to update with the data value—in this case, the note field. This replaces any current note stored in the NOTES field currently stored with the contact. We then create the Uri for the specific contact we will update. A simple call to the update() method of the ContentResolver class completes our change. We can then confirm that only one row was updated.

Now that you cluttered up your contacts application with sample user data, you might want to delete some of it. Deleting data is fairly straightforward.

Let’s start with a sample query implementation. Any query implementation needs to return a Cursor object. One convenient way to get a Cursor object is to return the Cursor from the underlying SQLite database that many Content Providers will use. In fact, the interface to ContentProvider.query() is compatible with the SQLiteQueryBuild.query() call. This example uses it to quickly build the query and return a Cursor object.

First, the code gets an instance of a SQLiteQueryBuilder object, which builds up a query with some method calls. Then, the setTables() method configures which table in the database will be used. The UriMatcher class checks to see which specific rows are requested. UriMatcher is discussed in greater detail later.

Next, the actual query is called. The Content Provider query has fewer specifications than the SQLite query, so the parameters are passed through and the rest is ignored. The instance of the SQLite database is read-only. Because this is only a query for data, it’s acceptable.

Finally, the Cursor needs to know if the source data has changed. This is done by a call to the setNotificationUri() method telling it which URI to watch for data changes. The call to the application’s query() method might be called from multiple threads, as it calls to update(), so it’s possible the data can change after the Cursor is returned. Doing this keeps the data synchronized.

The UriMatcher class is a helper class for pattern matching on the URIs that are passed to this Content Provider. It is used frequently in the implementations of the Content Provider functions that must be implemented. Here is the UriMatcher used in these sample implementations:

First, arbitrary numeric values are defined to identify each different pattern. Next, a static UriMatcher instance is created for use. The code parameter that the constructor wants is merely the value to return when there is no match. A value for this is provided for use within the UriMatcher class itself.

Next, the URI values are added to the matcher with their corresponding identifiers. The URIs are broken up in to the authority portion, defined in AUTHORITY, and the path portion, which is passed in as a literal string. The path can contain patterns, such as the “#” symbol to indicate a number. The “*” symbol is used as a wildcard to match anything.

The insert() method is used for adding data to the Content Provider. Here is a sample implementation of the insert() method:

The Uri is first validated to make sure it’s one where inserting makes sense. A Uri targeting a particular row would not, for instance. Next, a writeable database object instance is retrieved. Using this, the database insert() method is called on the table defined by the incoming Uri and with the values passed in. At this point, no error checking is performed on the values. Instead, the underlying database implementation throws exceptions that can be handled by the user of the Content Provider.

If the insert was successful, a Uri is created for notifying the system of a change to the underlying data via a call to the notifyChange() method of the ContentResolver. Otherwise, an exception is thrown.

The update() method is used to modify an existing row of data. It has elements similar to the insert() and query() methods. The update is applied to a particular selection defined by the incoming Uri.

In this block of code, a writable SQLiteDatabase instance is retrieved and the Uri type the user passed in is determined with a call to the match() method of the UriMatcher. No checking of values or parameters is performed here. However, to block updates to a specific Uri, such as a Uri affecting multiple rows or a match on TRACKPOINT_ID, java.lang.UnsupportedOperationException can be thrown to indicate this. In this example, though, trust is placed in the user of this Content Provider.

After calling the appropriate update() method, the system is notified of the change to the URI with a call to the notifyChange() method. This tells any observers of the URI that data has possibly changed. Finally, the affected number of rows is returned, which is information conveniently returned from the call to the update() method.

Now it’s time to clean up the database. The following is a sample implementation of the delete() method. It doesn’t check to see if the user might be deleting more data than they should. You also notice that this is similar to the update() method.

Again, a writable database instance is retrieved and the Uri type is determined using the match method of UriMatcher. If the result is a directory Uri, the delete is called with the selection the user passed in. However, if the result is a specific row, the row index is used to further limit the delete, with or without the selection. Allowing this without a specific selection enables deletion of a specified identifier without having to also know exactly where it came from.

As before, the system is then notified of this change with a call to the notifyChange() method of ContentResolver. Also as before, the number of affect rows is returned, which we stored after the call to the delete() method.

The last method to implement is the getType() method. The purpose of this method is to return the MIME type for a particular Uri that is passed in. It does not need to return MIME types for specific columns of data.

First, a couple of MIME types are defined. The Android SDK provides some guideline values for single items and directories of items, which are used here. The corresponding string for each is vnd.android.cursor.item and vnd.android.cursor.dir, respectively. Finally, the match() method is used to determine the type of the provided Uri so that the appropriate MIME type can be returned.