Greg-DB Dropbox Community Moderator

[Cross-linking for reference: https://stackoverflow.com/questions/33655061/display-file-names-in-list-view-from-dropbox-and-also-allow-to-download-selected ] It looks like you already found the Android Core SDK, which should suit your needs here. (Alternatively, you could use the new Java SDK for Dropbox API v2.)…

This should be fixed in the latest version of the SDK. Let us know if you're still having any trouble.

Thanks! This is a known issue that should be resolved in the next version of the SDK. Specifically, the SDK will be updated so that the value used for Files.ThumbnailSize.xs is instead 'w32h32'.

It's not currently possible to do this via the Dropbox API, but this is the right place to make this request. Thanks for the detailed of what you would like the interface to look like. I've sent it along to the team as a feature request.

[Cross-linking for reference: https://stackoverflow.com/questions/35743478/how-to-get-thumbnails-for-image-dropbox-sdk-c-sharp ] Here's a simple example that works for me to save a thumbnail of a file in Dropbox at "/test.jpg" to a local file on my computer: public async Task GetThumbnail(string path) { using (var response…

The GetThumbnailAsync method gives you IDownloadResponse<FileMetadata>. As shown in the documentation there, there are three different GetContent methods you can call on the response to get the content of the thumbnail requested. For example, you could get the thumbnail data as a byte array by using: (in your sample though…

To close the loop here, this was fixed in version 0.7.1.

Thanks! This is a known issue that should be resolved in the next version of the SDK.

[Cross-linking for reference: https://stackoverflow.com/questions/35675997/dropbox-http-api-always-returns-not-currently-allowed-to-use-api-v2 ] Your app must be registered for the file type permission, which unfortunately isn't supported by API v2. You can register a new app with a different permission level here:…

You could use the Dropbox API to list files and folders without having the desktop client installed, e.g., using API v2 /files/list_folder. However, the API doesn't currently offer any sort of file hash or checksum. I'll send this along as a feature request though.

This isn't currently possible, but I'll send this along as a feature request.

There certainly shouldn't be anything on our side causing this. If the API was going to intentionally fail a request, it would respond with an actual HTTP error code, but -1001 is just a client side error code. The best practice is to only download files if/when you need them, but if you do need to download many files, the…

There isn't any particular limit on our side around 172 files. The -1001 error code corresponds to NSURLErrorTimedOut though, which can happen for a variety of reasons, e.g., if the network connection fails, or if your connection is too congested. How many simultaneous connections are you allowing? I've seen other…

How are you downloading the file when it does work? Are you using the Dropbox web site? Can you compare the file you get that way to the file you get via the API? E.g., compare the file lengths and/or hashes. Some other things that would be helpful in debugging this: - the rest of the relevant code (e.g., what do you do…

Hi David, apologies that the documentation and explorer aren't clear on how to use that. I'll send that along as feedback to get that fixed up. I'm glad to see you sorted this out already though.

This should return an error as expected now.

No update on this yet. I'll follow up here when this is resolved.

Thanks for the report! We're looking into it.

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.

Apologies for the inconvenience! The API v2 shared link endpoint doesn't return all of the same information. I've sent this along as a request but I can't offer a timeline for when it may be added to v2. 

Hi Tim, unfortunately that endpoint in API v2 doesn't currently return those particular pieces of information, but I'll be sure to pass this along as a feature request. 

The /2/sharing/get_folder_metadata endpoint you're referring to is for operating on shared folders, but you have a shared link (to a folder) which is a different kind of sharing functionality on Dropbox and so uses a different ID. If you want information about a shared link, for a file or folder, you can use…

We changed it to not respect the period in a query, e.g., so if you just search for ".mov" the results will include "test.mov" but not "not a movie file.txt". 

Hi Matias, quick update: searching by file extension should be working now.

Thanks for the feedback Matias! The team is aware of these differences and difficulties with search in API v2 versus v1 and hopes to address them in the future. I can't offer a timeline for when improvements may be available though. I've included your feedback as feature requests for the various improvements to API v2…

To close the loop here, this was fixed in version 0.7.1.

Thanks! I can reproduce this. We'll look into it.

What version of the SDK are you using? If it's not up to date, please update it and let us know if you're still seeing this. Thanks!

The redirect_uri being supplied in that /authorize URL is: "urn:ietf:wg:oauth:2.0:oob". That doesn't start with https://, and as such isn't allowed by Dropbox's OAuth 2 implementation, per the error message. You'll need to use an https:// (or localhost) redirect URI instead. If it's helpful for your case, Dropbox provides…

Hi Fábio, can you elaborate on the issue you're seeing? It sounds like you are properly seeing the error message on the /authorize page. OAuth 2 redirect URIs for the "code" flow do need to start with "https://", unless it's a localhost address.