My task is to display the supported document types on an iPhone with OS 3.x, such as .pdf, .rtf, .doc, .ppt, .png, .tiff etc.
Now, I have stored these files only encrypted on disk. For security reasons, I want to avoid storing them unencrypted on disk.
Hence, I prefer to use loadData:MIMEType:textEncodingName:baseURL: instead of loadRequest: to display the document because loadData allows me to pass the content in a NSData object, i.e. I can decrypt the file in memory and have no need to store it on disk, as it would be required when using loadRequest.
The problem is that loadData does not appear to work with all file types:
Testing shows that all picture types seem to work fine, as well as PDFs, while the more complex types don't. I get a errors such as:
NSURLErrorDomain Code=100
NSURLErrorDomain Code=102
WebView appears to need a truly working URL for accessing the documents as a file, despite me offering all content via the NSData object already.
Here's the code I use to display the content:
[webView loadData:data MIMEType:type textEncodingName:@"utf-8" baseURL:nil];
The mime-type is properly set, e.g. to "application/msword" for .doc files.
Does anyone know how I could get loadData to work with all types that loadRequest supports? Or, alternatively, is there some way I can tell which types do work for sure (i.e. officially sanctioned by Apple) with loadData? Then I can work twofold, creating a temp unencrypted file only for those cases that loadData won't like.
Update
Looks like I'm not the first one running into this. See here:
http://osdir.com/ml/iPhoneSDKDevelopment/2010-03/msg00216.html
So, I guess, that's the status quo, and nothing I can do about it.
Someone suggested a work-around which might work, though:
http://osdir.com/ml/iPhoneSDKDevelopment/2010-03/msg00219.html
Basically, the idea is to provide a tiny http server that serves the file (from memory in my case), and then use loadRequest. This is probably a bit more memory-intensive, though, as both the server and the webview will probably both hold the entire contents in memory as two copies then, as opposed to using loadData, where both would rather share the same data object. (Mind you, I'll have to hold the decrypted data in memory, that's the whole point here).