views:

506

answers:

1

The the client side of a content provider consumer I can do something like this, to get a proper InputStream for reading the picture:

InputStream is = getContentResolver().openInputStream(pictureUri);

It is a nice API, and will on the server side, the actual content provider result in a call to:

public ParcelFileDescriptor openFile(Uri uri, String mode) throws FileNotFoundException {
  // Open a proper ParcelFileDescriptor, most likely using openFileHelper(uri, mode)
}

But what if the picture mapped to the URI is not to be found on the filesystem, but as a memory resource, or generated on the fly.

Can I create a memory mapped File or InputStream, or anything else, so that I am not required to save a temporary file to disk, just to be able to return it to my content provider consumer?

A: 

This is tough. You might be able to get away with using anything that can use a Socket interface. I haven't done it, but this is what makes me think so:

http://developer.android.com/reference/android/os/ParcelFileDescriptor.html#fromSocket%28java.net.Socket)

And a Socket could, in theory, be an Internet resource, or most anything...if you're willing to work at the Socket level. I would probably just give up and create the temporary file. Perhaps that makes me a coward.

Klondike
That is a solution that might work, but not as I want to do it. I really want to be able to consistently use the `ContentResolver#openInputStream()` method for reading all kinds of remote data. Regardless of how the server creates/gets the data. It is a question of not exposing the server implementation to the client.
PeyloW