516 CHAPTER 14: Android Content Providers: Providing Data to Applications
The schema for Content Providers is always the word “content.” A colon and a double forward
slash (://) always appear in the front of the URI reference and separate the data schema from the
data authority.
The next part of the URI is known as the data authority for the Content Provider. As you might have
expected, the authority for each Content Provider must be unique. An authority naming convention
usually follows your Java package naming conventions. Most organizations choose to use the
backward dot-com domain name of their organization, plus a data qualifier for each content provider.
Thus the previous example would assume that you own the hellouniverse.com domain name,
which, of course, you do not.
Since the Android developer documentation recommends that you utilize the fully qualified class
name of your ContentProvider subclass, you might then name your ContentProvider subclass
GalaxyDatabase.java if you were following this example Content URI. I am going to use the
ContactGalaxy.java Activity subclass name in the next section, to follow the Java class naming
convention used throughout this book.
The third part of the URI standard is the data path to the data. Although it is optional, it is a fairly
standard practice for organizational purposes. You would not usually put your data in the root folder
of a server where it would get lost; instead, you place it in a galaxy folder, using sub-folders for each
of the galaxy database tables. In this example, one subfolder would be a galaxy named Andromeda.
The Content Provider for the Android MediaStore (which you looked at in the previous section of the
chapter) database, for example, will utilize different path names to make sure that the audio, image,
and video files are kept in separate data type (data table) locations. By using different path names,
one single Content Provider can accommodate many different types of data that are in some way
related, such as the different new media content types, for example, kept in the MediaStore Content
Provider in the different data tables.
For unrelated data types, it is standard programming practice that you would want to utilize a
different Content Providers subclass, as well as a different data authority (and path, for that matter)
for each database.
The last URI reference specification component is the ID, which, as you may have surmised, needs
to be unique and numeric. This ID, or _ID in Android, is utilized whenever you want to access one
single database record.
So, as you can see, the URI reference specification progresses from the most general or high-level
(content://) specification, through the authority (server name), down through the pathway to the data
(directory path), and ultimately, to the data record itself (_ID).
Since you are using the default OS support suggested in the New Android Application Project of
API Level 8 (2.2) through API Level 19 (4.4), you will use the more modern (that is, not deprecated)
Content Providers for the Android Content Provider example, which you will be creating during the
rest of this chapter.
Let’s get started by creating your new Activity subclass, called ContactGalaxy.java, and add it
to your Android Manifest XML file, as well as to your application’s OptionMenu object, using a
MenuItem object with a menu label of “Contact Galaxy Ruler.” For your UI design layout, take a look
at the Android TableLayout container class, since databases use “tables” and since this is a UI layout
container that you are likely going to want to use someday to format your data in a tabular format.