6

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?

PeyloW
  • 36,742
  • 12
  • 80
  • 99

2 Answers2

1

As of android-9, you can make a pipe using ParcelFileDescriptor. You can stuff up to 64k in it and be done with it, or you can set up another thread to fill it after its been read. See the answer here for more detail:

Custom ContentProvider - openInputStream(), openOutputStream()

Community
  • 1
  • 1
Hans-Christoph Steiner
  • 2,572
  • 31
  • 30
1

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(java.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.

Eric Mill
  • 3,455
  • 1
  • 25
  • 26
  • 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 Oct 12 '09 at 09:44
  • @PeyloW did you find a solution to this? I am looking for a solution too. – Sunny Jan 18 '12 at 22:00
  • @Sunny None that is not a hack. So I ended up saving temp files and sending file descriptors. – PeyloW Jan 19 '12 at 08:21
  • creating a temporary file does work and is faster, better yet I'm creating a provider for caching another provider, so I have a solution that's simple and faster. One contentprovider deals with caching and pass the request to another one for generation. The only downside is wasting SD space. – Luiz Felipe May 15 '20 at 12:41