25

I am writing an Android application that interfaces with a RESTful service. This web service essentially fronts a file system, and provides metadata as well CRUD access to the files. My application retrieves the metadata, and exposes it to 3rd party apps through a ContentProvider.

I need to add the ability for 3rd party applications, running on the same device as my app, to CRUD the actual files by making requests to/from my app (not directly with the server). This means they need to either send or receive the contents of the files (which are typically XML or images) through my app.

I have thought of two approaches for implementing this:

Option 1 - Using ContentProvider.openFile

This seems like an obvious choice for giving 3rd party applications the ability to read files from my ContentProvider. I think it starts getting tricky when those applications need to create or update files through my `ContentProvider'. I'll need a callback when they are finished in order to know when to send the new/changed file back to the server. I believe I could use a FileObserver for that purpose though.

Option 2 - Using a Messenger through a Service

With this approach, I can send the files between my application and client applications through the Messenger. The files would have to be passed through a Bundle, so I am not sure what the best format is for transmitting them (File, FileDescriptor, byte array, something else??). I don't have a good handle on whether or not this would cause problems if the files get to be large.

Option 3 - a hybrid approach

  1. Use folder(s) on external storage as a drop box
  2. Communicate CRUD requests, and drop box contents, through a Messenger/Service
  3. Use the ContentProvider to store the status of requests
  4. 3rd party app receives status updates through a ContentObserver

Summary

I think using ContentProvider would be the ideal solution, but it seems that the API does not fully support my use case. I am concerned that trying to go down that path might result in a kludgy implementation. If I go with a Messenger and Service approach, I am uncertain of the most robust way to transfer the files through a Bundle.

The hybrid approach seems pretty robust, but the most complex to implement. Files aren't actually being passed around, so performance should be good. However, I fear this is over-architecting the solution.

What is the best approach for transferring files between applications running on the same Android device? Of course, I am open to other options which I have not outlined in my question.

Eric Levine
  • 13,536
  • 5
  • 49
  • 49
  • 4
    I would do it the same way as Android. Storing the files on the sdcard and providing access to the file URIs not the file content through a ContentProvider. – mibollma Aug 31 '11 at 15:04
  • i use option 1 for retrieve only, it fits the purpose. i don't think updating and inserting should be any more complex - you do have a crud interface with a contentprovider, after all. – njzk2 Aug 31 '11 at 15:04
  • @mibollma - I like that idea, but I'm not sure it will solve the entire problem – Eric Levine Aug 31 '11 at 16:54
  • 1
    I would start by taking a close look at the docs as well as the source to see if the concept fits your needs. At least it sounds somewhat similar. Here is the source: http://android.git.kernel.org/?p=platform/packages/providers/MediaProvider.git;a=blob;f=src/com/android/providers/media/MediaProvider.java;hb=HEAD – mibollma Aug 31 '11 at 17:01
  • Android is naturally a mobile OS, where 1st class persistency should be Web. Applications should access only their own files and never share them, by design. So attempt to go against the spirit of platform will need hacking. Which is not good. –  Aug 31 '11 at 19:56
  • 1
    @elevine What about embedding a little http server that 3rd party apps can communicate through. All requests would be via localhost. Haven't tried this before, but it seems like a simple approach. – dbryson Aug 31 '11 at 21:56
  • @RocketSurgeon You are completely wrong. The Android platform provides several mechanisms for sharing files between applications, no hacking required! – Eric Levine Aug 31 '11 at 22:50
  • @dbryson That is an interesting idea. I know there is a version of Jetty for Android (http://code.google.com/p/i-jetty/). I'll have to look into it some more. – Eric Levine Aug 31 '11 at 22:52
  • @elevine - if you embed an http server, use a unix domain socket rather than a tcp one, so that the client apps don't require Internet permission. – Chris Stratton Sep 03 '11 at 18:37

3 Answers3

16

Content provider is definitely the way to go. If you consider that google uses this approach for almost everything then it becomes appaentr that this is the intended design method.

I'm not extolling the virtues of them, but in the land of the blind, the one eyed content provider is king.

Update

There is an example of how to do this in CommonsWare book, see the link provided.

Source of Content Provider/Files

Use the synch framework for content providers. Simply maintain a list of requests and then schedule the sync to download those file. You can also do this on network tickles etc. you can use broadcast intents or contentobserver to notify clients that the file is downloaded.

In essence this is probably similar to your 3rd option but importantly it uses the Android supplied tools rather than rolling your own.

Ad Endum

Best place to start is the android SDK sample in: android-sdk\samples\android-8\SampleSyncAdapter but be warned that there's a load of contacts related stuff that masks the juicy bits. It took me a while to figure out that I could delete almost all of it except the syncadapter

Moog
  • 10,193
  • 2
  • 40
  • 66
  • I think the ContenProvider API is missing some key features for my use case though. I need allow 3rd party apps to request files be downloaded, and then get notified when they are ready. I've found the implementation of this to be kludgy with a ContentProvider and ContentObserver. Also, my ContentObservers weren't reliably firing their onChange events. Switching over to a Service/Messenger based solution has been faring much better. I haven't implemented the situation of a 3rd party app requesting a file be uploaded yet, but this seems like a poor fit for aContentObserver. – Eric Levine Sep 09 '11 at 13:17
  • Use sych as detailed in my update. There is an example of synch in the android sdk – Moog Sep 09 '11 at 14:03
  • I think you're right, the sync adapter approach seems like an improvement. Do you have any other pointers for good resources to learn it? I've been basing my attempt on the first two patterns from the Google I/O 2010 Android REST talk. Its probably worth overcoming the sync adapter learning curve and implementing the third pattern: http://www.google.com/events/io/2010/sessions/developing-RESTful-android-apps.html – Eric Levine Sep 09 '11 at 15:00
  • Afraid I had to struggle through the same leaerning curve. I've updated with the SDK sample. The only other resource I used was the [did you win yet](http://www.c99.org/2010/01/23/writing-an-android-sync-provider-part-1/) tuorial. – Moog Sep 09 '11 at 15:19
3

http://developer.android.com/reference/android/os/ParcelFileDescriptor.html can be sent between processes. I believe that there is a subtly where these are explicitly blacklisted from being allowed to be put in intents. They can be sent through AIDL though. Also, do NOT use the sdcard for this. This is just asking for trouble. One sdcard is world readable, so anyone can see it. Also, you do not always have access to write to the sdcard (it is removed or put in UMS).

Bishnu
  • 853
  • 7
  • 11
2

Using the SD card is definitely the recommended way to go to share files on Android.

However, I would go with a modified hybrid solution which makes use of startActivityForResult() and onActivityResult() (docs here) on the client side to communicate CRUD requests (and getting the Uri to the file(s) on the SD card if needed) if you don't mind creating a dummy activity as a front end to your service. Clients, once finished with the file(s), can call startActivityForResult() again to alert your app to changes.

Of course this can be done with startService()/bindService() however it doesn't provide an easy way for clients to obtain a status result especially if you need IPC.

Although content providers/resolvers feel like the correct way to go about things, I do feel it is more for single direction requests specific to providing/consuming content.

Jasoneer
  • 2,078
  • 2
  • 15
  • 20
  • I don't think startActivityForResult and onActivityResult quite hit the mark. When an application wants to share a file with my app, it will not be starting one of my app's Activities. Also, I'm finding that with a Messenger, you can do two way communications through IPC relatively easily. – Eric Levine Sep 05 '11 at 15:23
  • I'm looking over IPC with a Service again and it's not too bad. It depends on if the clients are okay implementing the service binding callbacks and using Messages, but I could see how startActvityForResult and onActivityResult wouldn't work for you. It would be nice if they had a startServiceForResult. – Jasoneer Sep 05 '11 at 18:05