Greg-DB Dropbox Community Moderator

Hi Brian, I just replied on the new thread you started, but in short, yes, that's correct, the Dropbox API doesn't currently offer file hashes, so you'd need to download it to check the contents.

Yes, even the date would change. The file size will always indicate the size of the file contents, though we don't recommend using that as a way to identify the actual contents of course.

The Dropbox API doesn't offer any sort of file hash or checksum unfortunately, but I'll be sure to pass this along as a feature request.

Alexander, it sounds like you already sorted some of this out, so I'll follow up on the latest thread you replied on, so as not to spam others on these threads.

Dropbox API v2 now offers this via the endpoint /sharing/get_shared_link_metadata: https://www.dropbox.com/developers/documentation/http/documentation#sharing-get_shared_link_metadata

The Swift SDK uses API v2, which doesn't currently have an equivalent of /metadata/link. I believe it is planned, but I don't have a timeline to offer right now.

[Edit to offer a simpler solution] The /metadata/link endpoint allows the app to get additional metadata (path, size, etc.) as well as individual links to files within the folder the link points to. To do so, call /metadata/link with the shared link as the link parameter, as well as the desired sub-path as the path…

1. The URL given to the Saver is supposed to be a URL of a file that will be saved to the end user's Dropbox account. The Saver won't be able to download from a localhost URL though. The URL you supply to the Saver is sent off to the Dropbox servers to download, which can't access your local machine and the file it is…

Quick follow up here for anyone looking who hasn't already seen it, the API v2 Java SDK does now have the equivalent of createTemporaryDirectUrl as getTemporaryLink.

Do you mean com.dropbox.core.BadResponseException? Each method should document the exceptions it can through. For example, the new download method can throw IllegalArgumentException, DownloadErrorException, or DbxException. For example, it would throw IllegalArgumentException if a parameter is in the wrong format, e.g.,…

Unless I misunderstand your scenario, you shouldn't need to include both. The 2.0.0 version also include the API v1 calls that 1.8.1 has. I.e., it contains both DbxClientV1 and DbxClientV2.

That's correct, DeletedMetadata doesn't contain a file ID, but we'll consider this a feature request as well. And yes, listFolderContinue can raise ListFolderContinueErrorException where ListFolderContinueError.RESET would indicate a reset, in which case you should start over with listFolder.

1) Yes, in API v2, you would use listFolder and listFolderContinue instead of getDelta. You should check if each entry is a FileMetadata, FolderMetadata, or DeletedMetadata to distinguish between files, folders, and deleted items, respectively. 2) API v2 doesn't currently have an equivalent of createTemporaryDirectUrl, but…

This method and write mode seems to be working properly for me, so a few questions to help figure this out: - What version of the SDK are you using? - Are you getting any error or output? - Can you print out the result you're getting in "updated" (e.g., updated.PathLower)? - Are you uploading the same content? If you…

Per the tutorial, the URL scheme you register in CFBundleURLSchemes should be "db-APP_KEY", where "APP_KEY" is your app key. You have just "APP_KEY" registered. This is how the Dropbox app redirects the user back to your app, so just add "db-" to the beginning of that and that should fix it.

Thanks! We'd need to see the actual setupWithAppKey call with your key, as well as where you set up your db-APP_KEY scheme in your plist for this though. If you'd rather not share those publicly, you can open an API ticket here: https://www.dropbox.com/developers/contact

The null error in the simulator is expected, since the Dropbox app isn't installed, but it should fall back to the built-in authorization flow. The restriction in iOS 9 only applies to canOpenURL, and not openURL, so the official Dropbox app itself does not need to register the URL schemes of every app that uses the SDK.…

Hi Aibek, when you see this behavior, does your ListFolderResult have hasMore set to true? If so, you need to call listFolderContinue to get the rest of the results. You should have code to handle that in any case, but I don't see a mention of listFolderContinue in your post. Let me know if you are already handling that…

Two other things I just noticed: - You don't seem to actually be constructing your client anywhere that you've shared. E.g.: self.restClient = [[DBRestClient alloc] initWithSession:[DBSession sharedSession]]; self.restClient.delegate = self; - You're printing out the contents of the local file immediately after kicking off…

For loadFile, you just need these two: - (void)restClient:(DBRestClient*)client loadedFile:(NSString*)destPath; - (void)restClient:(DBRestClient*)client loadFileFailedWithError:(NSError*)error; Earlier you did say you implemented them, but I wanted to check since that's the only thing that seemed to be missing from the…

Nothing jumps out at me, besides the lack of implementation of the delegate methods. Have you finished implementing those and looked into the causes I mentioned that may lead to them not being called?

The iOS Core SDK doesn't do any caching for you, and I'm not sure what functionality you're referring to in DBRoulette. The DBRoulette sample app displays images, not text, anyway, unless you're referring to a modified version of it? Anyway, there are a few things that might cause your delegate methods to not be called: 1.…

Have you implemented both of the delegate methods? - (void)restClient:(DBRestClient*)client loadedFile:(NSString*)destPath; - (void)restClient:(DBRestClient*)client loadFileFailedWithError:(NSError*)error; What do you get from those?

Tokens don't expire by themselves (but they can be manually revoked). What doesn't work exactly? What error or output are you getting?

You just need to call credentialStoreForUserID once to get your access token/secret, which you can do anywhere in the app, as long as the account is already linked. That would look like: MPOAuthCredentialConcreteStore *creds = [[DBSession sharedSession] credentialStoreForUserId:@"12345"]; NSLog(@"access token key: %@…

I recommend working through the tutorial to see how to call methods in that SDK. For example: [self.restClient loadMetadata:@"/"]; So, using loadAccountInfo would look something like: [self.restClient loadAccountInfo]; And you'd need to implement these delegate methods to get the response: -…

That SDK uses OAuth 1 and version 1 of the Dropbox API, a.k.a. the Core API. The DBRestClient.loadAccountInfo method corresponds to /account/info.

Are you using an SDK or library? If so, which?

You can get your user ID from the account information API call (/account/info on v1, or /users/get_current_account on v2).

The access token secret is not the same thing as the app secret. If you're using OAuth 1, the access token secret is the "oauth_token_secret" returned by /oauth/access_token. If you're using OAuth 2, the access token is just one string, and doesn't have a separate "secret" portion.