OpenURL local file or force UIDocumentInteractionController to use a specific application

Question

I want to open a file (saved locally in my application) with another application.

I am currently using openURL (there is a dedicated url scheme), and it works fine if I use a file hosted on the Internet, but I would like to use a local file so that: a) it works offline b) many times when my users either do not have a mobile phone zone or roaming internationally

What I tried so far: I was not lucky that openURL used a local file, I tried several approaches, but they all seem to be like

NSString *filePath = [[NSBundle mainBundle] pathForResource:@"test" ofType:@"ext"]; NSURL *fileURL = [NSURL fileURLWithPath:filePath]; [[UIApplication sharedApplication] openURL:fileURL]; 

also

  NSURL *fileURL = [[NSBundle mainBundle] URLForResource: @"test" withExtension:@"ext"]; [[UIApplication sharedApplication] openURL:fileURL]; 

also manually, using strings with different path options localhost / and file: // and var / mobile etc

nothing works (for me anyway)

So, I looked around and came across a UIDocumentInteractionController

I can use the UIDocumentInteractionController to allow the user to open my local file with another application - however, it always has several options for using other applications, and, for example, Dropbox can be one of the other applications.

I do not want the user to upload (or technically download) a copy of my file for other uses. It contains data that I would rather not make so easily accessible.

When a file is opened by my intended application (not made by btw by me), it does not allow saving or accessing raw data.

I understand that by including a file in my application, anyone who is serious about purchasing it can, I just don’t want to upload a large menu, saying: “Here it is, if you want your own copy to make a derivative work with ''

Ideally, I could use openURL, but I think this is because of the “sandbox” that the other application doesn’t respond to - in Android, I use mode_world_readable to declare the file as readable by other applications (therefore placing it outside the sandbox and it doesn’t allows other applications to write on it, just read) - is there anyway to do the same with iOS?

Otherwise, if I can force the UIDocumentInteractionController to use a specific application and not present a menu, that would be fine too.

A similar question was asked a while ago.

Sorry for the long read, any help is appreciated.

Edit: I just got a response from Apple Tech support, and they told me that this is currently not possible (right after iOS 6)

Answer 1

Yes, you are limited due to the strict sandbox on iOS. Here are a few thoughts.

You can override the functionality of the UIDocumentInteractionController, instead subclassing the QLPreviewController instead. You can then replace the standard button element that displays the Open In menu. Take a look at this post for one solution for subclassing QLPreviewController: QLPreviewController remove or add UIBarButtonItems

Of course, I believe that working between applications works mostly out of your hands. If the application is registered in order to be able to process a certain type of file, it will be displayed as one of the options in the "open" list, whether you want it or not. I do not believe that you can filter which applications appear in this list.

Here are two experimental ideas that I thought of but never tried:

• You can encode base64 data from the file you are trying to transfer, which simply converts the binary code to text, and transfer it as part of the custom URL used to run another application. Then another base64 application can decode the same data back to binary. On the other hand, there is a limitation on the length of the URL, which means that the “file” you submit must be quite small.

• Further, and I don’t even know if this is possible, but I wonder if you can use the steganograhpy algorithm to embed the document data inside the image, and then transfer it to the camera roll. Then another application can open the camera roll and decode the image back to the data again .... Yes. I know ... it's unclear, but it might be interesting to try .; -)

Not sure if this helps, but you said that "any help is appreciated" .; -)

Sincerely.