Android Content Provider-Implementation of the ContentProvider MIME type

The ContentProvider MIME type has two methods to return the MIME type. GetType () is a method implemented for any provider. GetStreamTypes () If your provider provides files, this method is expected to be implemented. The getType () method of table MIME types returns a String in MIME format, which describes the data type calculated by the content URI parameter. Uri can be a mode rather than a specific URI. At this time, you should return the data types that match the content URI mode. Standard MIME types should be returned for common data types, such as text, HTML, or JPEG, and getType. A complete list of standard MIME Types can be found on the iana mime Media Types website. For the content Uris that point to one or more rows of table data, getType () should return an Android vendor-specific MIME format: Type part: vnd-child type part: · if the URI points to a single row: android. cursor. item/If URI points to multiple lines: android. cursor. dir/· Provider-specific part: vnd. <name>. <type> You Need To provide <name> and <type>. The value of <name> must be globally unique, and the value of <type> must be unique for the corresponding URI mode. A good choice for <name> is to use your company name or a part of your app's Android package name. A good choice for <type> is to use the string that marks the table associated with the URI. For example, if the authority of a provider is com. example. app. provider, and it exposes a table named table1, which indicates that the MIME type of multiple rows in the table is: vnd. android. cursor. dir/vnd.com. example. provider. table1 indicates that the MIME type of a single row is vnd. android. cursor. item/vnd.com. example. provider. table1 indicates the object MIME. If your provider provides the object, you must implement getStreamTypes (). This method returns a String array consisting of the MIME types pointing to the object to the imported content URI. You should overwrite the MIME type parameter with the MIME type parameter, therefore, you only return the MIME types required by the client. For example, assume that a provider provides image files, including. jpg,. png, And. gif. If an application uses the filter string image/* (indicating something that is "image"), it calls ContentResolver. getStreamTypes (), then ContentProvider. the getStreamTypes () method should return an array: {"image/jpeg", "image/png", "image/gif"} if the application is only interested in .jpg files, it should use the filter string * \/jpeg to call ContentResolver. getStreamTypes (), and ContentProvider. getStreamTypes () should return: {"image/jpeg"} if your provider does not provide the MIME requested in the filter string, getStreamTypes () should return null. implement a Contract (Contract) class Contract class is a public final class, which includes Constants of URIs, column names, MIME types, and other metadata used for providers. This class creates a contract between the provider and other applications to ensure that the operation is still correct when the values of the URI, column name, and other items change. A contract class is helpful to developers because it provides a well-recognized name without directly using numbers, so developers will not use incorrect values for column names or Uris. Because it is a class, it can contain Javadoc documents. Integrated development environment. For example, Eclipse can automatically complete the constant name with the contract class and display Javadoc for the constant. Developers cannot operate contractual class files from your applications, but they can statically compile them into their applications from the. jar files you provide. The ContactsContract class and its Nested classes are examples of contract classes. The permission to implement Content Provider has a detailed description of all Permissions of the android System in the topic Security and Permissions. Topic Data Storage also describes the impact of security and permissions on various Storage types. In short, the important points are: · by default, the data files stored in the internal memory of the device are private to your applications and providers. · The SQLiteDatabase you created is private to your application and provider. · By default, data files stored in external storage are public and globally readable. You cannot use a content provider to restrict operations on files stored in external storage, because other applications can use other APIs to read and write files. · The methods used to open or create files or SQLite data in your device's internal memory may secretly give read and write permissions to other applications. If you use an internal file or database as the data warehouse of your provider, and you give them "world-readable" or "world-writeable" permissions, your permission statement to your provider in manifest will not protect your data. The default permission for files and databases in internal storage is "private", and you should not change the permission of your provider's data warehouse. If you want to use the content provider permission to control operations on your data, you should store your data to internal files, SQLite databases, or "cloud" (for example, in a remote service), and you should keep files and databases private to your application. All applications with permission can read or write your provider from your provider, even if the background data is private. Because by default, your provider does not have permission settings. To change this situation, you can set the permissions of your provider in the manifest file and use the attributes of the <provider> element or its son element. You can set the permissions applied to the entire provider, or apply only to specific tables, specific records, or all three. You can use one or more <permission> elements in the manifest file to define the permissions of your provider. The permissions to be used by your provider are unique and are limited by the Java-style range for the android: name attribute. For example, name the read permission com. example. app. provider. permission. READ_PROVIDER. the descriptions listed below describe the range of the provider permission, which is applied to the entire provider and then becomes finer granularity. More granular permissions have higher priority than a large range of permissions: A single read-write provider-level permission controls the read and write permissions of the entire provider, use the android: permission attribute of the <provider> element. Separate read and write provider-level permissions control one read permission and one write permission for the entire provider. You can use the android: readPermission and android: writePermission attributes of the <provider> element to specify them. They have a higher priority than android: permission. The Path-level permission has the read, write, or read/write permissions on the content URI in your provider. You can use the <provider> element <path-permission> sub-element to specify the permissions for each URI. You can specify a read/write permission, a read permission, or a write permission, or all three. Read and Write Permissions take precedence over read/write permissions. In addition, the path-level permission has a higher priority than the provider-level permission. A temporary permission is also a permission level, which indicates that the application has temporary permissions, even if the application does not have permissions. The temporary permission feature reduces the number of permissions that an application needs to declare in its mainifest. When you open temporary permissions, only applications that continuously operate on all your data need to have "persistent" permissions on your provider. consider the permissions you need to implement an email provider and application when you want to allow an external image view application to display image attachments through your provider. To grant the required permissions to the image view application without declaring permissions, you must set the temporary permissions for the image content URI. Design your email application in this way: when a user wants to display an image, your application sends an intent to the image viewing application, which contains the image content URI and permissions. After you view an image, you can request your email provider to obtain the image, even if the image viewing application has no common read permission on your provider. To enable temporary permissions, you can set the android: grantUriPermissions attribute of the <provider> element, you can also add one or more <grant-uri-permission> child elements to your <provider> element. If you use temporary permissions, you must call Context. revokeUriPermission () When you delete the support for a content URI from your provider. If this content URI is associated with a temporary permission. The attribute value determines the operability of your provider. If the attribute is set to true, the system will obtain temporary permissions for your entire provider, overwriting any other permissions obtained through provider-level or path-level. If this flag is set to false, you must add the <grant-uri-permission> child element to your <provider> element. Each sub-element specifies which content URI or which Uris are granted temporary permissions. To delegate temporary permissions to an application, intent must contain the FLAG_GRANT_READ_URI_PERMISSION or FLAG_GRANT_WRITE_URI_PERMISSION flag, or both. They can be set using the setFlags () method. If the android: grantUriPermissions attribute does not exist, it is regarded as false.