How to store large blobs in an android content provider?

Question

I have some large files (images and video) which I need to store in a content provider. The android documentation indicates...

If you are exposing byte data that's too big to put in the table itself — such as a large bitmap file — the field that exposes the data to clients should actually contain a content: URI string. This is the field that gives clients access to the data file. The record should also have another field, named "_data" that lists the exact file path on the device for that file. This field is not intended to be read by the client, but by the ContentResolver. The client will call ContentResolver.openInputStream() on the user-facing field holding the URI for the item. The ContentResolver will request the "_data" field for that record, and because it has higher permissions than a client, it should be able to access that file directly and return a read wrapper for the file to the client. -- http://developer.android.com/guide/topics/providers/content-providers.html#creating

I am having some difficulty finding an example. In particular I wish to use the bitmap in the context an ImageView. Consider the following code quasi-code (it doesn't work)...

ImageView iv = ....
String iconUri = cursor.getString(cursor.getColumnIndex(Table.ICON));
iv.setImageURI(Uri.parse(iconUri));

Observations/Problems...

1. How can the stored/recovered uri be reconstructed correctly? (it is text in the table)

2. The setImageURI implementation makes use of the content resolve openInputStream so this should work.

   String scheme = mUri.getScheme();
   ...
   } else if (ContentResolver.SCHEME_CONTENT.equals(scheme)
           || ContentResolver.SCHEME_FILE.equals(scheme)) {
     try {
       d = Drawable.createFromStream(
               mContext.getContentResolver().openInputStream(mUri),
               null);
   

   --frameworks/base/core/java/android/widget/ImageView.java

I got it working. I took a hint from the MediaStore and MediaProvider. The files which contain the data are named based on the content provider (directory), the column name, the row id and the media type. The content resolver then acquires the file descriptor like so...

Uri iconUri = Uri.withAppendedPath(Table.getUri(cursor), Table.ICON);
ib.setImageURI(iconUri);

...and the content provider responds in kind...

@Override
public ParcelFileDescriptor openFile (Uri uri, String mode) {
int imode = 0;
if (mode.contains("w")) imode |= ParcelFileDescriptor.MODE_WRITE_ONLY;
if (mode.contains("r")) imode |= ParcelFileDescriptor.MODE_READ_ONLY;
if (mode.contains("+")) imode |= ParcelFileDescriptor.MODE_APPEND;
List<String> pseg = uri.getPathSegments();
if (pseg.size() < 3) return null;

try {
    File filePath = filePathFromRecord(pseg.get(2), pseg.get(1));
    return ParcelFileDescriptor.open(filePath, imode);
} catch (FileNotFoundException e) {
    e.printStackTrace();
}
return null;
}

Answer 1

The solution phreed gives in the bottom half of question is basically correct. I'll try to add some more details here.

When you do getContentResolver().openInputStream(...), content resolver will go to your content provider and call its openFile method. This is how the openFile looks in ContentProvider.java:

public ParcelFileDescriptor openFile(Uri uri, String mode)
     throws FileNotFoundException {
 throw new FileNotFoundException("No files supported by provider at "
         + uri);
}

So this explains where the "No files supported ..." error exactly comes from! You get around this by overriding openFile method in your subclass and providing your own implementation. It's neat: you get perfect control of where your files get placed when any client does openInputStream or openOutputStream.

Code sample in phreed's question gives a hint how the implementation could look like. Here's my slightly modified version which also creates directories and files as needed. I'm novice at this stuff so this might not be the optimal way of doing things, but it gives an idea. For one thing, it should probably check if external storage is available.

@Override
public ParcelFileDescriptor openFile(Uri uri, String mode) throws FileNotFoundException {
    File root = new File(Environment.getExternalStorageDirectory(), 
            "/Android/data/com.example.myapp/cache");
    root.mkdirs();
    File path = new File(root, uri.getEncodedPath());
    // So, if the uri was content://com.example.myapp/some/data.xml,
    // we'll end up accessing /Android/data/com.example.myapp/cache/some/data.xml

    int imode = 0;
    if (mode.contains("w")) {
            imode |= ParcelFileDescriptor.MODE_WRITE_ONLY;
            if (!path.exists()) {
                try {
                    path.createNewFile();
                } catch (IOException e) {
                    // TODO decide what to do about it, whom to notify...
                    e.printStackTrace();
                }
            }
    }
    if (mode.contains("r")) imode |= ParcelFileDescriptor.MODE_READ_ONLY;
    if (mode.contains("+")) imode |= ParcelFileDescriptor.MODE_APPEND;        

    return ParcelFileDescriptor.open(path, imode);
}

Answer 2

Android provides the helper method openFileHelper() that makes implementing the openFile() method very easy. All you have to do, to use this method, is to provide the location of the file in a column named “_data“.

@Override
public ParcelFileDescriptor openFile(Uri uri, String mode)
      throws FileNotFoundException {
   if (URI_MATCHER.match(uri) != PHOTO_ID) {
      throw new IllegalArgumentException
            ("URI invalid. Use an id-based URI only.");
   }
   return openFileHelper(uri, mode);
}

Click here for detail

Answer 3

There is a problem writing files though. How does the content provider know then the write is complete?

When closing an OutputStream obtained via a ContentResolver.openOutputStream() I wish for the corresponding (custom) ContentProvider to perform some custom action. Presently I am using creating a FileObserver on a temporary file but it seems like the wrong way to get it done. My first thought was to subtype the ParcelFileDescriptor produced by the ContentProvider.openFile() method but that didn't seem to work for me.

That being said there were some errors which resulted in the MyParcelFileDescriptor usage.

• I didn't ensure that the file descriptor would not be garbage collected prematurely.
• I didn't try to overriding finally() (the documentation seems to suggest that being the place to do this but close() seemed to be the right choice to me.

Bottom line, is there any interaction between the file objects as seen by the ContentResolver and those of the ContentProvider?