Lecture 9 Providers and Loaders

This lecture discusses how to access data from a Content Provider using a Loader. A Content Provider is an abstraction of a database or other data store, allowing us easily and systematically work with that data in Java (rather than in a separate data manipulation language such as SQL). A Loader is then used to efficiently perform this data access in the background (off the UI Thread), while also easily connecting that data to Views. This lecture discusses how to use a Loader to access the data in an existing Content Provider; a later lecture details how to create Content Providers from scratch.

This lecture references code found at https://github.com/info448/lecture09-loaders. Note that this demo accesses the device’s User Dictionary, which is only available to general apps on API 22 (Lollipop) or earlier. This tutorial thus does not support all versions of Android. You can instead use an emulator running API 22 or earlier.

9.1 Content Providers

The example starter code uses a ListView that shows a list of words. Recall that a ListView utilizes the model-view-controller architecture… and in this case, the “model” (data) is a hard-coded list of array of words. But there are other lists of words as well! Entire databases of words! Previous lectures have discussed how to use network requests to access online data APIs, but there are also databases (of words no less) built into your Android phone.

For example, Android keeps track of the list of the spellings of “non-standard” words in what is called the User Dictionary. You can view this list on the device at Settings > Language & Input > Personal Dictionary. You can even use this Settings interface to add new words to the dictionary (e.g., “embiggen”, “cromulent”, “covfefe”).

For security reasons, the User Dictionary is only available on devices running API 22 (Lollipop) or earlier**. This specific example will only work on older devices, but the concepts and code for accessing databases in general will apply to all versions. You can test this specific example using an emulator running API 22 or earlier.

Note that the User Dictionary keeps track of a database of words. You can think of this database as being like a single SQL table (or CSV spreadsheet, or R data frame): it’s a set of entries (rows) each of which have some values (columns). The primary key of the table is named (by convention) ID.

Since this data is stored in (essentially) a simple SQL table, it is possible for us to access and modify it programmatically&mash;moreover, the Android framework allows us to do this without needing to know or write SQL! For example, we can access this list of words in order to show them in the ListView.

While you don’t need to know SQL to utilize a built-in database like the User Dictionary, it helps to have a passing familiarity with relational databases and their terminology to intuit about the organization of the data.

To do this, we’ll need to request permission to access the database, just as we asked permission to access the Internet. Include the following in the Manifest:

<uses-permission android:name="android.permission.READ_USER_DICTIONARY"/>

Although the words are stored in a database, we don’t know the exact format of this database (e.g., the exact table or column names, or even whether it is an SQL database or just a .csv file!). We want to avoid having to write code that only works with a specific format, especially as the words may be stored in different kinds of databases on different devices or across different versions of Android. (The Android framework does include support for working directly with a local SQLite database, as discussed in a later chapter).

In order to avoid relying on the specific format of how some data is stored, Android offers an abstraction in the form of a Content Provider33. A Content Provider offers an interface to interact with structured data, whether that data is stored in a database, in a file, in multiple files, online, or somewhere else. You can thus think of “a Content Provider” as meaning “a data source” (e.g., the source/provider of content)!

  • Thinking of a Content Provider as a “server” you access is a decent metaphor.

  • It is possible to create your own Content Providers (described in a later chapter), but this lecture focuses purely on utilizing existing Providers.

All Content Providers (data sources) have a URI (Universal Resource Identifier, a generalization of a URL used for resources not necessarily on the Internet). It is possible to query this URI, similar in concept to how web APIs are accessed via queries to their URI endpoints. In particular, Content Provider URIs utilize the content:// protocol (instead of https://), since the their data is accessed as via “content requests” rather than “HTTP requests”.

The URI for the Dictionary’s content is defined by the constant UserDictionary.Words.CONTENT_URI. We utilize constants to refer to URIs and paths to make it easier to refer to them and to generalize across devices that may have different directory structures.

We are able to access this Content Provider via a ContentResolver. This class provides methods for accessing the data in a provider (represented as a ContentProvider object). Each Context has a singleton ContentResolver, which is accessed via the getContentResolver() method (note that for a Fragment, the Context is the containing Activity). The ContentResolver’s methods support the basic CRUD operations: insert() (create), query() (read), update(), and delete().

//java
ContentResolver resolver = getContentResolver();

ContentResolver methods take multiple parameters, supporting the different options available in a generic SQL query. For example, consider the the query() method:

getContentResolver().query(
    uri,              // The content URI
    projection,      // The an array of columns to return for each row
    selectionClause  // Selection criteria (as an SQL WHERE clause)
    selectionArgs,   // An array of values that can be injected into the selection clause
    sortOrder);      // The sort order for the returned rows (as an SQL ORDER BY clause)
  • This is basically a wrapper around an SQL SELECT statement! But each “part” of that statement are specified as parameter to this method.

The projection is a String[] of all the “columns” (attributes) we want to fetch from the data source. This is what you’d put after SELECT in SQL. (Note we can pass in null to represent SELECT *, but that’s inefficient—better to give a list of everything).

  • We can see what column names are available for the User Dictionary in UserDictionary.Words. Again, these are defined as constants!

  • Be sure to always select the _ID primary key: it will be needed later!

The other parameters can be used to customize the SELECT statement. The “selection” (WHERE) clause needs to parameters: the second are values that will be escaped against SQL injection attacks. Passing null for any of these parameters will cause the clause to be ignored:

//java
String[] projection = new String[] {
    UserDictionary.Words.WORD,
    UserDictionary.Words.FREQUENCY,
    UserDictionary.Words._ID
};
resolver.query(UserDictionary.Words.CONTENT_URI, projection, null, null, null);
//kotlin
val projection = arrayOf(
    UserDictionary.Words.WORD, 
    UserDictionary.Words.FREQUENCY, 
    UserDictionary.Words._ID
)
contentResolver.query(UserDictionary.Words.CONTENT_URI, projection, null, null, null)

So overall, the query is breaking apart the components SQL SELECT statement into different pieces as parameters to a method, so you don’t quite have to write the selection yourself. Moreover, this method abstracts the specific query language, allowing the same queries to be used on different formats of database (SQLite, PostgreSQL, files, etc).

9.2 Cursors

The ContentResolver#query() method returns a Cursor. A Cursor provides an interface to the list of records in a database (e.g., those returned by the query). A Cursor also behaves like an Iterator in Java: it keeps track of which record is currently being accessed (e.g., what the i would be in a for loop). You can think of it as a “pointer” to a particular record, like the cursor on a screen.

We call methods on the Cursor to specify which record we want it to “point” to, as well as to fetch values from the record object at that spot in the list. For example:

//java
cursor.moveToFirst(); //move to the first item
String field0 = cursor.getString(0); //get the first field (column you specified) as a String
String word = cursor.getString(cursor.getColumnIndexOrThrow("word")); //get the "word" field as a String
cursor.moveToNext(); //go to the next item
//kotlin
cursor.moveToFirst() //move to the first item
val field0 = cursor.getString(0) //get the first field (column you specified) as a String
val word = cursor.getString(cursor.getColumnIndexOrThrow("word")) //get the "word" field as a String
cursor.moveToNext() //go to the next item

The nice thing about Cursors though is that they can easily be fed into AdapterViews by using a CursorAdapter (as opposed to the ArrayAdapter we’ve used previously). The SimpleCursorAdapter is a concrete implementation that is almost as easy to use as an ArrayAdapter.

You instantiate a new SimpleCursorAdapter, passing it:

  1. A Context for loading resources
  2. A layout resource to inflate for each record
  3. A Cursor (which can be null)
  4. An array of column names to fetch from each entry in the Cursor (the projection, similar to before)
  5. A matching list of View resource ids (which should all be TextViews) to assign each column’s value to. This is the “mapping” that the Adapter will perform (from projection columns to TextView contents).
  6. Any additional option flags (0 means no flags, and is the correct option for us).
//java
adapter = new SimpleCursorAdapter(
                this,
                R.layout.list_item_layout, //item to inflate
                cursor, //cursor to show
                new String[] {UserDictionary.Words.WORD, UserDictionary.Words.FREQUENCY}, //fields to display
                new int[] {R.id.txt_list_item, R.id.txt_item_freq},                       //where to display them
                0); //flags
//kotlin
adapter = SimpleCursorAdapter(
        this,
        R.layout.list_item_layout, //item to inflate
        cursor, //cursor to show
        arrayOf(UserDictionary.Words.WORD, UserDictionary.Words.FREQUENCY), //fields to display
        intArrayOf(R.id.txt_item_word, R.id.txt_item_freq), //where to display them
        0 //flags
)

Then we can use this adapter for the ListView in place of the ArrayAdapter!

9.3 Loaders

In order to get the Cursor to pass into the adapter, we need to .query() the database. But we want to do this a lot in fact, every time the database updates, we’d like to be able to query it again so we can update the Adapter and have the changes show up! Additionally, accessing a database can be slow (it requires disk access, structuring and submitting SQL calls, and depending on the complexity of the database those queries can take time). Thus, as with network requests, we’d like to perform this query on a background thread so that it doesn’t block our application and cause it to stall.

In order to automatically update your list with new data loaded on a background thread, we’re going to use a class called a Loader. This is basically a wrapper around ASyncTask (described in a later chapter), but one that lets you execute a background task repeatedly whenever the data source changes. In particular, Android provides a CursorLoader specifically used to load data from ContentProviders through Cursors—whenever the content changes, a new Cursor is produced which can be “swapped” into the adapter.

Loaders are being deprecated in Android P (API 28), in favor of the “Architecture” package classes such as ViewModel and LiveData. But many of the same ideas will apply.

To use a CursorLoader, we need to specify that our Activity implements the LoaderManager.LoaderCallbacks<Cursor> interface—basically saying that this Fragment can react to Loader events.

We will need to fill in the interfaces callback functions in order to use the CursorLoader:

  • In onCreateLoader() we specify what the Loader should do. Here we will instantiate and return a new CursorLoader(...) that queries the ContentProvider. This looks a lot like the .query() method we wrote earlier, but will run on a background thread!

  • In the onLoadFinished() callback, we can use swapCursor() to swap passed in Cursor into our SimpleCursorAdapter in order to feed that model data into our controller (for display in the view). The framework handles any cleanup around the old Cursor.

  • In the onLoaderReset() callback, we can just swap in null for our Cursor, since there now is no content to show (the loaded data has been “reset”).

Finally, in order to actually start our background loading, we’ll use the getLoaderManager().initLoader(...) method. This will cause the Android framework to request the creation of a new Loader (by our onCreateLoader() method), as well as start that Loader loading! (This uses a manager similar to FragmentManager, and is similar in flavor to AsyncTask.execute()).

getSupportLoaderManager().initLoader(0, null, this);
  • Use getSupportLoaderManager() if you’re using the support library (and calling from an Activity; a support library Fragment like we’ve been using only has the one manager, so you can just use getLoaderManager()).

The first parameter to the initLoader() method is an id number for which cursor you want to load—what is passed in as the first param to onCreateLoader() (or is accessible via Loader#getId()). This allows you to have multiple Loaders using the same callback function (e.g., to handle multiple Loaders for multiple data sources). The second param is a Bundle of args, and the third is the LoaderCallbacks (e.g., who handles the results)!

  • Note that you can use the .restartLoader() method to “recreate” the CursorLoader (without losing other references), such as if you want to change the arguments passed to it.

And with that, we can fetch the words from our database on a background thread—and if we update the words (e.g., through the Language Settings) it will automatically update!

9.4 Other Provider Actions

The Content Resolver of course allows us to do more than just query and load the data: we can also add, update, or remove entries from the database.

  • If we want to modify the contents of the User Dictionary, we will need permission:

    <uses-permission android:name="android.permission.WRITE_USER_DICTIONARY"/>

To insert (create) a new Word into the ContentProvider, we call the .insert() method on the ContentResolver. It is passed a ContentValues object, which is a HashMap almost exactly like a Bundle (but it only supports values that can be entered into Content Providers, e.g., no Parcelables).

//java
ContentValues newValues = new ContentValues();
newValues.put(UserDictionary.Words.WORD, inputText.getText().toString());
newValues.put(UserDictionary.Words.FREQUENCY, 100);
newValues.put(UserDictionary.Words.APP_ID, "edu.uw.loaderdemo");
newValues.put(UserDictionary.Words.LOCALE, "en_US");

Uri newUri = getContentResolver().insert(
       UserDictionary.Words.CONTENT_URI,   // the user dictionary content URI!
       newValues                   // the values to insert
);
//kotlin
val newValues = ContentValues()
newValues.put(UserDictionary.Words.WORD, inputText.text.toString())
newValues.put(UserDictionary.Words.FREQUENCY, 100)
newValues.put(UserDictionary.Words.APP_ID, "edu.uw.loaderdemo")
newValues.put(UserDictionary.Words.LOCALE, "en_US")

val newUri = contentResolver.insert(
        UserDictionary.Words.CONTENT_URI, // the user dictionary content URI!
        newValues                   // the values to insert
)
  • The insert() function returns the URI for the newly inserted row, e.g. if you want to be able to query and display that content later.

A similar approach is used to update and modify an entry in the Content Provider: call the .update() method and pass in a ContentValues bundle of values to change:

//java
ContentValues newValues = new ContentValues();
newValues.put(UserDictionary.Words.FREQUENCY, newFrequency);

getContentResolver().update(
          ContentUris.withAppendedId(UserDictionary.Words.CONTENT_URI, id),
          newValues,
          null, null); //no selection
//kotlin
val newValues = ContentValues()
newValues.put(UserDictionary.Words.FREQUENCY, newFrequency)

contentResolver.update(
        ContentUris.withAppendedId(UserDictionary.Words.CONTENT_URI, id),
        newValues, null, null //no selection
)
  • Note that we make sure to update only that particular item by specifying the URI of that item. We do this by constructing a new URI representing/identifying that item, effectively by appending an "/:id" path parameter to the URI. This means that we don’t need to use the selection criteria (though we could do that as well).

That covers how to utilize and interact with a Content Provider (as a client of that Provider). A later lecture will cover how to implement a Provider for a custom database.

  1. https://developer.android.com/guide/topics/providers/content-providers.html↩