Creating a Content Provider 创建一个内容提供器
A content provider manages access to a central repository of data. You implement a provider as one or more classes in an Android application, along with elements in the manifest file. One of your classes implements a subclassContentProvider, which is the interface between your provider and other applications. Although content providers are meant to make data available to other applications, you may of course have activities in your application that allow the user to query and modify the data managed by your provider.
The rest of this topic is a basic list of steps for building a content provider and a list of APIs to use.
Before You Start Building
Before you start building a provider, do the following:
Decide if you need a content provider. You need to build a content provider if you want to provide one or more of the following features:
You want to offer complex data or files to other applications.
You want to allow users to copy complex data from your app into other apps.
You want to provide custom search suggestions using the search framework.
You don't need a provider to use an SQLite database if the use is entirely within your own application.
If you haven't done so already, read the topic Content Provider Basics to learn more about providers.
Next, follow these steps to build your provider:
Design the raw storage for your data. A content provider offers data in two ways:
File data
Data that normally goes into files, such as photos, audio, or videos. Store the files in your application's private space. In response to a request for a file from another application, your provider can offer a handle to the file.
"Structured" data
Data that normally goes into a database, array, or similar structure. Store the data in a form that's compatible with tables of rows and columns. A row represents an entity, such as a person or an item in inventory. A column represents some data for the entity, such a person's name or an item's price. A common way to store this type of data is in an SQLite database, but you can use any type of persistent storage. To learn more about the storage types available in the Android system, see the sectionDesigning Data Storage.
Define a concrete implementation of the ContentProvider class and its required methods. This class is the interface between your data and the rest of the Android system. For more information about this class, see the sectionImplementing the ContentProvider Class.
Define the provider's authority string, its content URIs, and column names. If you want the provider's application to handle intents, also define intent actions, extras data, and flags. Also define the permissions that you will require for applications that want to access your data. You should consider defining all of these values as constants in a separate contract class; later, you can expose this class to other developers. For more information about content URIs, see the sectionDesigning Content URIs. For more information about intents, see the sectionIntents and Data Access.
Add other optional pieces, such as sample data or an implementation of AbstractThreadedSyncAdapter that can synchronize data between the provider and cloud-based data.
Designing Data Storage
A content provider is the interface to data saved in a structured format. Before you create the interface, you must decide how to store the data. You can store the data in any form you like, and then design the interface to read and write the data as necessary.
These are some of the data storage technologies that are available in Android:
The Android system includes an SQLite database API that Android's own providers use to store table-oriented data. TheSQLiteOpenHelper class helps you create databases, and theSQLiteDatabase class is the base class for accessing databases.
Remember that you don't have to use a database to implement your repository. A provider appears externally as a set of tables, similar to a relational database, but this is not a requirement for the provider's internal implementation.
For storing file data, Android has a variety of file-oriented APIs. To learn more about file storage, read the topicData Storage. If you're designing a provider that offers media-related data such as music or videos, you can have a provider that combines table data and files.
For working with network-based data, use classes in java.net andandroid.net. You can also synchronize network-based data to a local data store such as a database, and then offer the data as tables or files. TheSample Sync Adapter sample application demonstrates this type of synchronization.
Data design considerations
Here are some tips for designing your provider's data structure:
Table data should always have a "primary key" column that the provider maintains as a unique numeric value for each row. You can use this value to link the row to related rows in other tables (using it as a "foreign key"). Although you can use any name for this column, using BaseColumns._ID is the best choice, because linking the results of a provider query to aListView requires one of the retrieved columns to have the name_ID.
If you want to provide bitmap images or other very large pieces of file-oriented data, store the data in a file and then provide it indirectly rather than storing it directly in a table. If you do this, you need to tell users of your provider that they need to use a ContentResolver file method to access the data.
Use the Binary Large OBject (BLOB) data type to store data that varies in size or has a varying structure. For example, you can use a BLOB column to store aprotocol buffer or JSON structure.
You can also use a BLOB to implement a schema-independent table. In this type of table, you define a primary key column, a MIME type column, and one or more generic columns as BLOB. The meaning of the data in the BLOB columns is indicated by the value in the MIME type column. This allows you to store different row types in the same table. The Contacts Provider's "data" tableContactsContract.Data is an example of a schema-independent table.
Designing Content URIs
A content URI is a URI that identifies data in a provider. Content URIs include the symbolic name of the entire provider (itsauthority) and a name that points to a table or file (a path). The optional id part points to an individual row in a table. Every data access method ofContentProvider has a content URI as an argument; this allows you to determine the table, row, or file to access.
The basics of content URIs are described in the topic Content Provider Basics.
Designing an authority
A provider usually has a single authority, which serves as its Android-internal name. To avoid conflicts with other providers, you should use Internet domain ownership (in reverse) as the basis of your provider authority. Because this recommendation is also true for Android package names, you can define your provider authority as an extension of the name of the package containing the provider. For example, if your Android package name iscom.example.<appname>, you should give your provider the authority com.example.<appname>.provider.
Designing a path structure
Developers usually create content URIs from the authority by appending paths that point to individual tables. For example, if you have two tablestable1 and table2, you combine the authority from the previous example to yield the content URIscom.example.<appname>.provider/table1 and com.example.<appname>.provider/table2. Paths aren't limited to a single segment, and there doesn't have to be a table for each level of the path.
Handling content URI I
补充：移动开发 , Android ,
