Access to full files/direct URL via Preview SDK

[davegreco]

Currently there is the existing function fileURLForContentPreviewCacheEntryForFile which returns a valid file url for the cached document. However, these files are encrypted and this url is not of much use.

We are in need of a function similar to retrievePreviewImageForFile:(BOXFile *)file completion:(BOXImageBlock)completionBlock that returned temporary access to an unencrypted version of a cached file for external use that could be cleared once you are done with it. With respect to file permissions for the user of the app, of course.

The use case for this may be to make it an attachment to a message of some kind, hand it off to another app for editing such as Office/etc, or many other uses that we may not have yet thought of.

[RicoYao]

I believe the best way to accomplish the use case you described would be to download the file directly through the base SDK:
https://github.com/box/box-ios-sdk/blob/master/doc/Files.md#download-a-box-file

The Preview SDK often does not download the actual file, but rather alternate formats of that file that are most appropriate for preview in an iOS app. For example, an MS Office document may not be fetched by the Preview SDK as the raw docx/xlsx/etc, but rather as an image generated by Box servers, and that image would not be appropriate for sending as an attachment of editing in another app. In addition, the formats that get used to preview files is subject to change, so even if we do happen to use the original today, that might not be the case in the future, and that's why there's no public interface exposed for getting at that file in the manner you described.

[boxtcarpel]

Just to quickly clarify: For apps using the Preview SDK, and wanting to leverage it's cache, it makes sense to have an "export" functionality which will perform a download of the original file content if necessary (and then place it in the cache).
This is something we were already working on and will follow up on soon.

[davegreco]

Thank you for your consideration and effort on this issue.

We believe that this makes a lot of sense to exist here.

For our implementation, the lack of it would result in duplicating a lot of effort and significantly increasing the size on disk for all content.

A flag or mask (indicating thumb, preview, raw or any combination there of) of some kind when caching the file (I don't know how aggressive the SDK is about caching the raw file, if at all currently) while using cacheFileWithID to indicate if the raw file should be cached vs just a preview would be ideal, as at least in our situation, we'd only need to preserve the raw file for PDF forms that will need to be filled out and shared via e-mail. However, for others I could see this being useful with Word Documents, Excel, etc... While manually downloading the file contents is definitely one route to go, it just feels like this managed cache is a better place for all of this.

The current Box.com app on the Apple App Store now has an "open in" feature, which I'd imagine would benefit from sharing this same cache. It doesn't appear to be available offline unless you've opened it at least once. It's nearly impossible to know if this is leveraging the cache here at all or if you are also maintaining a separate downloads directory for these files when sharing them. It's just very difficult for me to understand why you'd go through that trouble vs leveraging this existing system that is likely setup very well to handle this exact thing, even if it requires a little work to do so.

This page may not be accurately depicting what is happening either. But based on this here, we assumed that file content was the raw file and that under at least some circumstances it was being leveraged to store the raw contents for the cached file.

https://github.com/box/box-ios-preview-sdk/blob/master/doc/PreviewCaching.md

Preview Caching

We are caching the following types of items in the local file system:

file content
file previews
thumbnails

We hope that this feature can make it into this tool so that we can preserve it's place in our existing work flow and continue to get the most that we possible can out of the Preview SDK.