I've created 2 test applications:
In the one the documents are included into the bundle and can be opened by using the quick look controller.
In the other app, the documents are downloaded. When I try to open the files the quick-look controller simply shows a message saying an error occurred. Strangely it will open downloaded PDF documents without any problems.
I suspect it has something to do with headers and mime-types, but I'm not sure on this. Would anyone know what the reason could be that downloaded .doc or .docx documents won't open and local documents will?
It turned out to be a problem with saving the downloaded files. At first I was writing the data to a filepath URL. This saved the data to the right location, but the type of file wasn't recognized anymore.
The solution was to use the default FileManager to save the file.
[[NSFileManager defaultManager] createFileAtPath:filePath contents:data attributes:nil];
Related
I use AWS SDK iOS v2.8.2 to upload and download files to AWS S3 and it works great with the exception of application packages (.app). As these packages are basically layers of sub-folders that's how I have been uploading and downloading them, but the .app files are corrupted or damaged when I try to run them (after upload or download). This is how I download a file from AWS S3 (upload is the same except I have defined contenType as well):
NSURL *downloadedLocationURL=[NSURL fileURLWithPath:downloadedLocationstring];
NSFileManager *fileManager= [NSFileManager defaultManager];
[fileManager createDirectoryAtPath: [downloadedLocationURL.URLByDeletingLastPathComponent path]
withIntermediateDirectories:YES
attributes:nil
error:NULL];
self.transferUtility = [AWSS3TransferUtility S3TransferUtilityForKey:currentBucket.regionShortName];
[self.transferUtility downloadToURL:downloadedLocationURL
bucket:bucket.name
key:key
expression:expression
completionHandler:completionHandler]
I realized that I need to upload the package in a different way but I am not sure how to. Should I define the contentType in any way? Should I rather compress any package content and upload as a .zip file? Most other file formats seem to function correctly so I wonder what is the trick with app packages may be that I am unable to see.
Thanks for your help.
Have you confirmed through AWS S3 console that the uploaded object is as you expect it to be?
You can directly download the file from the AWS console and reference it back where you need it to first ensure that the upload was done correctly. My other guess is to do with playing around with setting the content-type on your upload.
I'm trying to adopt iCloud Drive to store backups of the data of my application using a single file for each backup, if it's relevant they're simple XML files with a custom extension. File creation and upload are working fine but as I'm now trying to let the user manually delete backups I found out that I cannot delete the file programmatically but I can do it if I go to iCloud Drive from the app on iOS or the folder in Finder on macOS.
To save the files I first retrieve the root for the container with
FileManager.default.url(forUbiquityContainerIdentifier: nil)?.appendingPathComponent("Documents")
and create the Document folder if it doesn't exists as I want the user to be able to view and edit the files, after creating the file locally in the temporary directory I upload it with
let file = FileManager.default
if file.fileExists(atPath: remotePath.path) {
try? file.removeItem(at: remotePath)
}
try? file.setUbiquitous(true, itemAt: localPath, destinationURL: remotePath)
where remotePath is the path retrieved before with the file name appended. To load the files I use a NSMetadataQuery and get the path of each file with NSMetadataItemURLKey on each returned item, which is working fine but when I attempt to
try? FileManager.default.removeItem(at: retrievedPath)
it works if the same device created the file but if it is from another one it always fail and the error says that the file does not exists at the specified path.
I've removed error handling code for clarity but I've tested this behaviour inspecting the thrown error.
How can I delete any file even from other devices, am I missing some steps?
I was indeed missing something, after reading this question, in particular this answer, I found out that even if the NSMetadataQuery returns the path correctly is possible that the file has not been downloaded to the the device, hence the error.
To correctly delete a file you have to mimic the behaviour of UIDocument and use a NSFileCoordinator on a background queue, refer to the answer referenced before for implementation details.
I have a problem reading a Strings file created dynamically inside my app's document directory.
Basically, I create and read my file using:
[[NSFileManager defaultManager] createFileAtPath:filePath contents:fileData attributes:nil];
NSLog(#"%#", [targetBundle localizedStringForKey:#"MY_STRING" value:#"#" table:#"test"]);
The file is created in the document directory, and the targetBundle also points to this directory.
The above code works very well when the strings file already exists in the document directory when the app runs.
So, if I delete the Strings file from the document directory, the NSLog displays: #.
When I run again the application (the file already exists), NSLog displays MY_LABEL's value.
I guess that the bundle loads its resources once at the launch, but how can I be sure to read my new file even if it has just been created?
Thank you for your help,
Julian
I didn't find how to reload a bundle but I fixed this problem by creating an empty file with the same name BEFORE the creation of the bundle.
With that, the bundle "knows" the file and if the file dynamically changes, the content is up-to-date (because the file is read at runtime).
I'm storing files in my application sandbox in a way that masks the original name of the file.
For example I have a file called abc.png which is stored in the sandbox as obfuscated.png.
When I do an open in of this file in another application using a UIDocumentInteractionController I'd like to have the other file open the file with the filename abc.png
Currently the other app opens the file as obfuscated.png.
I have tried changing the name property of the UIDocumentInteractionController in documentInteractionControllerWillPresentOptionsMenu as well as willBeginSendingToApplication, however in both cases the receiving application does not get the correct filename - it continues to show the obfuscated filename.
Apart from creating a copy of the file with the unobfuscated name, is there a way to make the receiving application use the desired filename?
Instead of a copy try:
NSError *error = nil;
[[NSFileManager defaultManager] linkItemAtPath:obfuscatedFilePath toPath:abcFilePath error:&error];
This will create a hard link to the file. Symbolic links will not work.
I have a little problem with my app when updating to iOS5.
In my documents directory I have a sqlite file and PDF documents.
The sqlite file contains the url's of the PDF documents.
When I start my app, I can see the list of documents, which is saved in the sqlite file.
But when I want to open a pdf, the document is not found.
So I think iOS changes the document directory addresses.
Is that possible?
I save the addresses of my pdf's like that:
NSArray *pathArr = NSSearchPathForDirectoriesInDomains(NSDocumentDirectory,
NSUserDomainMask,
YES);
NSString *filename = [NSString stringWithFormat:#"%#/%#/%#",[pathArr objectAtIndex:0],title,versionString];
It's difficult to answer your question without mor information. The fact that you are able to read the sqlite file which you say is in the Documents folder indicates that your program can at least find that file.
You can look and see what exactly is in the Documents folder by setting the
Application Supports iTunes file sharing
attribute in the Application's info.plist file. You can then view the Application's Documents folder and add/remove files in iTunes.
You can also look in the
~Library/Application Support/iPhone Simulator/<IOSVERSION>/Applications/<UUID>/Documents
directory if you are running the simulator.
You will at least know what the actual contents of the Documents directory are...