I am trying to transition from Dropbox API v1 to v2. My objective is to upload video files to Dropbox in the app folder that Dropbox creates for the apps that do not require access to root folder. I checked this tutorial but have the following confusions:
NSData *fileData = [#"file data example" dataUsingEncoding:NSUTF8StringEncoding allowLossyConversion:NO];
// For overriding on upload
DBFILESWriteMode *mode = [[DBFILESWriteMode alloc] initWithOverwrite];
[[[client.filesRoutes uploadData:#"/test/path/in/Dropbox/account/my_output.txt"
mode:mode
autorename:#(YES)
clientModified:nil
mute:#(NO)
inputData:fileData]
setResponseBlock:^(DBFILESFileMetadata *result, DBFILESUploadError *routeError, DBRequestError *networkError) {
if (result) {
NSLog(#"%#\n", result);
} else {
NSLog(#"%#\n%#\n", routeError, networkError);
}
}] setProgressBlock:^(int64_t bytesUploaded, int64_t totalBytesUploaded, int64_t totalBytesExpectedToUploaded) {
NSLog(#"\n%lld\n%lld\n%lld\n", bytesUploaded, totalBytesUploaded, totalBytesExpectedToUploaded);
}];
What should be "/test/path/in/Dropbox/account/my_output.txt" in my case, as I do not access the root folder?
Whether the same code is supposed to work for binary files such as mp4 files (it uses UTF8 encoding in the sample code when preparing NSData)?
The "/test/path/in/Dropbox/account/my_output.txt" in the sample is just an example. You should supply the path for the desired location of the uploaded file in the Dropbox account. If you're using an app folder app, the root you supply will automatically be translated into the app folder itself. For example, if you have an app folder at "/Apps/MyAppName", and you want to upload a file named "video.mp4" into a folder called "Videos" in your app folder, you should supply a path value of "/Videos/video.mp4". That will automatically become /Apps/MyAppName/Videos/video.mp4 in the account.
The sample makes an NSData by encoding a string, but you can use the same uploadData to upload a file from any NSData.
Basically this path is /test/path/in/Dropbox/account/my_output.txt.
In dropbox account it will create folders like this test>path>in>Dropbox>account-- then your file will be in account folder. You can replace it with
/yourFolderName/Yourfilename.extension
Related
Im trying to overwrite an uploaded file to Dropbox.
Instead of replacing the file, Dropbox keeps adding another conflicted copy,
I have got the metadata for the file using
for (DBMetadata *file in metadata.contents) {
NSLog(#" %# metadata %#", file.filename,file.rev);
}
prints myFile.sqlite metatdata 5372f37f73G
Im uploading the file with:
[restClient uploadFile:#"myFile.sqlite" toPath:#"/Data" withParentRev:#"5372f37f73G" fromPath:filePath];
checked How to overwrite file with parent rev using Dropbox API in iOS?
How to avoid "conflicted copy" when uploading to dropbox from iOS client
dropbox keeps creating conflicted copies ios sdk (core api)
What am I missing here?
I was calling the wrong folder for meta data in - (void)restClient:(DBRestClient *)client loadedMetadata:(DBMetadata *)metadata {
For anyone else
//Calls all files for your app folder
[self.restClient loadMetadata:#"/"];
//Calls a folder you created within your app folder
[self.restClient loadMetadata:#"/yourfolder"];
So I'm pretty lost with this one and really new to epub files. I've done a bit of searching but can't seem to put everything together in my head.
My app uses DropBox's Chooser API to get a file from a user's DropBox folder. In this case, I want to open up a .epub file. So when the user chooses a file, the DropBox API gives me back an NSURL object to that file. For example:
https://dl.dropboxusercontent.com/1/view/e8bmxpkree6nc67/The%20Art%20of%20War.epub
And now, I've tried a couple different tools to try to read this file. Originally, I tried using KFEpubKit. But when I called:
epubURL; // The url from DropBox (shown above)
NSURL *documentsURL = [[[NSFileManager defaultManager] URLsForDirectory:NSDocumentDirectory inDomains:NSUserDomainMask] lastObject];
self.epubController = [[KFEpubController alloc] initWithEpubURL:epubURL andDestinationFolder:documentsURL];
self.epubController.delegate = self;
[self.epubController openAsynchronous:YES]
I would get back an error that the file couldn't be unzipped. The error reads as:
Epub Error: Error Domain=KFEpubKitErrorDomain Code=1 "Could not extract epub file." UserInfo=0x170275400 {NSLocalizedDescription=Could not extract epub file.}
I looked into the code and narrowed down the problem a little bit. The KFEpubKit uses the SSZipArchive utility to unzip files. And from this point on, I'm a bit stuck. The [SSZipArchive unzipFileAtPath: toDestination:] call seems to be failing when used with the epubURL.path. I'm not sure if this has something to do with the fact that my file is a .epub extension and not a .zip extension. Or maybe there's some stuff to do after getting the URL from DropBox and before giving it to the KFEpubKit tool?
In the end, I'm expecting to have to display the text of the book with a UIWebView. But I'm just not sure how to handle this .epub file. What should I do with the file from Dropbox? Any help is much appreciated.
A quick glance indicates that that SSZipArchive wants a local file URL, not a remote HTTP URL. Try downloading the file first (NSData with contents of URL, then write to some temp file) then create a file URL that points to the temp file, and send that into the KFEpubController:
// Download the file from dropbox
epubURL; // The url from DropBox (shown above)
NSData * epubData = [NSData dataWithContentsOfURL:epubURL];
NSString * tempPath = [NSTemporaryDirectory() stringByAddingPathComponent:#"temp.epub"];
[epubData writeToFile:tempPath atomically:YES];
NSURL *tempURL = [NSURL URLWithString:tempPath];
NSURL *documentsURL = [[[NSFileManager defaultManager] URLsForDirectory:NSDocumentDirectory inDomains:NSUserDomainMask] lastObject];
self.epubController = [[KFEpubController alloc] initWithEpubURL:tempURL andDestinationFolder:documentsURL];
// etc.
(Coding from memory.) All normal caveats apply here-- you'll want to do proper progress/error handling on the download, get rid of the temp file, etc, etc.
When I try to load a shared item, the data that comes back is dropbox's login page - as if I weren't authenticated.
Here is the current method I am using to get the file data:
[itemProvider loadItemForTypeIdentifier:docType options:nil completionHandler:^(NSURL *url, NSError *error) {
//my code
}];
doctype is an appropriate kUTType like kUTTypeImage or kUTTypeText, for example. The mimeType that we write the file with is correct to, per other files. It's the actual content loaded from dropbox (just a login page every time).
I have used other variations of the method (UIImage *, and NSData *) but get the same result for dropbox files.
Our shared extension works fine with files that are downloaded in apps like goodreader or Files. The problem arises when I try to share a file from the dropbox app. It gives me a url that I can put into any browser and it will take me to the file, so the url is not the problem.
Has anyone else faced this?
Here is an example link to a document that does this:
https://www.dropbox.com/s/qxkd1957qf7iq9x/04%20-%20Test%20Document.doc?dl=0
Thank you for your help on this Greg. I found that this worked instead by just changing the url and setting dl=1 like so
From:
https://www.dropbox.com/s/qxkd1957qf7iq9x/04%20-%20Test%20Document.doc?dl=0
To https://www.dropbox.com/s/qxkd1957qf7iq9x/04%20-%20Test%20Document.doc?dl=1
I am using Dropbox sync api for downloading text file and upload video file from/to dropbox via my ios application.
I am struggling while uploading heavy video file.While i am uploading video file of duration 15 to 20 minutes its uploaded correctly, but if the duration is more than 25 minutes
then it gets memory waring and app crashes.
I am using this code on upload button action
DBPath *paths=[[DBPath root] childPath:[self.allVideoArray objectAtIndex:Selectedvideo]];
DBFile *createfile=[filesystem createFile:paths error:nil];
NSData *data=[[NSData alloc]initWithContentsOfFile:self.path];
[createfile writeData:data error:nil];
[data relese];
Please some body way me out from this problem. Any help should be appreciable, Thanks in advance.
The problem is that you create an NSData instance containing the entire file. If the file is too big to fit into memory your app will crash. There are better ways to write large files to a DBFile.
Since you have a path to the local file you could do:
DBPath *paths=[[DBPath root] childPath:[self.allVideoArray objectAtIndex:Selectedvideo]];
DBFile *createfile=[filesystem createFile:paths error:nil];
[createFile writeContentsOfFile:self.path shouldSteal:NO error:nil];
Another option would be to read the file at self.path in smaller chunks and use DBFile appendData:error:.
Side note - you really need to check return values to make sure these calls are working or not and make use of the error parameter to log the cause of the problem (if any).
I am developing a app like file manager. In this i have created zip folder using any existing folder, it works perfectly fine. For this i have used SSZipArchive API. After zip i send it through mail. It's working fine too.
Now when i try to zip any empty folder, it is not working. Means empty folder does not zip.
Yeah looking at the source code, the method + createZipFileAtPath:withContentsOfDirectory: only appears to care about files:
while ((fileName = [dirEnumerator nextObject])) {
BOOL isDir;
NSString *fullFilePath = [directoryPath stringByAppendingPathComponent:fileName];
[fileManager fileExistsAtPath:fullFilePath isDirectory:&isDir];
if (!isDir) {
[zipArchive writeFileAtPath:fullFilePath withFileName:fileName];
}
}
You have two choices:
Fix it yourself and then send a pull request to the author on github and contribute to work you have, yourself, benefited from.
Live with it. It's not clear how an empty folder not appearing in the zip file is an issue anyway.
Isn't a standard thing to have stub files in directories like that. Some file with no contents.