Greg-DB Dropbox Community Moderator

Thanks for pointing that out! It looks like the documentation needs to be updated. You can use the builder to build this call with the desired options, like this: ListFolderResult result = client.files().listFolderBuilder("").withRecursive(true).start();

Oh, I see, thanks! For upload and download calls in particular, you won't get the failure when you're offline, since those are automatically handled on a background session. (And in fact, they should automatically continue when you get back online.) 

Thanks for checking that. It does look like that should be getting filled out then, so I'm not sure exactly what's causing it on your system. In testing this, I was actually able to get mine stuck on null as well though. I was able to fix it by: * running "Clean Build Folder" (in the Xcode "Product" menu, while holding…

Thanks for the report! I'm not seeing this issue when testing on a device where the WiFi is off before/while making an API call though. I am getting a -1009 error. So that we can try to reproduce this and investigate, can you let me know: - what version of iOS you're seeing this on - how you're constructing the client…

Dropbox does offer an API you can use to upload and download files without using the official Dropbox desktop application. You can find everything you need to get started with the Dropbox API, including documentation, tutorials, and SDKs here: https://www.dropbox.com/developers

Thanks! Is that the exact code you're trying though? I don't see the Dropbox client object itself. You just seem to be calling a separate search method. Also, note that you need to implement the response callback. Just taking the return value won't give you what you're looking for. The search method is an RPC-style call,…

This should be fixed now.

This should be fixed now.

No, the Dropbox API doesn't offer anything like that, but I'll be sure to pass this along as a feature request.

Thanks! I was able to reproduce the issue by removing the value for CFBundleIdentifier. Yours is $(PRODUCT_BUNDLE_IDENTIFIER), so make sure that "Product Bundle Identifier" is set in your target's Build Settings. That's listed in the Packaging section.

I don't see in your code where you're attempting the search call. Can you share that part? Thanks!

Thanks! The expected result here is that the dialog would show the app name, and clicking "Allow" would send the user back to the app. Can you share your plist file? That controls how your app is registered for this. In particular, for the null app name issue, I think CFBundleIdentifier may be relevant.

The endpoints for adding templates aren't currently exposed, as the feature is still in development. I'll send this along as a request for them though.

Since you're using Swift, are you using the official SwiftyDropbox SDK? In that case, you'd use the search method in FilesRoutes. As long as the call succeeds, it will return a SearchResult. You can then use the SearchResult.matches, which is an array of SearchMatch. SearchMatch.metadata contains the FileMetadata for the…

I'm not sure off hand what may be causing this. Can you share a screenshot showing this so I can make sure I understand exactly what you're seeing and try to reproduce it? Thanks in advance!

It looks like you opened a new thread for this, so I'll take a look and reply there: https://www.dropboxforum.com/t5/API-support/Dropbox-api-v2-null-Do-you-want-to-allow-this-page-to-open-null/m-p/201802#M9540

Using the Dropbox API, you can search for files and folders under a particular path using the /2/files/search endpoint: https://www.dropbox.com/developers/documentation/http/documentation#files-search If you're using an official SDK, there will be a corresponding search method for that.

That's the OAuth 2 "token" flow, where the access token is returned on the redirect URI fragment. That's meant more for client-side apps. For server-side apps, you should use the "code" flow. You can find more information here: https://www.dropbox.com/developers/documentation/http/documentation#authorization

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

The app authorization flow redirect is directed by the db-<APP_KEY> URL scheme registered in an app's plist file, in the CFBundleURLTypes section. It sounds like you have the same app key registered in both DBMacApp and ezReceiptMac, causing the undesired redirect. Since DBMacApp was just for testing, the easiest solution…

We're able to reproduce the issue, so we shouldn't need any more information from your side. Thanks though!

This is a bug with the library itself, and not something you should have to handle yourself. We're looking into it, but I don't have a timeline for a fix right now.

Thanks! By the way, for reference, the path is also localized for accounts in other languages, and users can move and rename app folders whenever they want.

No, the Dropbox API doesn't expose a way for apps with the app folder app to query their full app folder path. The API is designed such that apps shouldn't need to know their own app folder path though. I.e., when such an app references a path using the API, the API automatically translates the root to be the app folder…

[Cross-linking for reference: https://stackoverflow.com/questions/41592694/how-to-get-upload-progress-with-java-sdk-for-dropbox-api-v2] The API v2 Java SDK doesn't currently expose progress listeners for uploads, but I'll be sure to pass this along as a feature request. 

The API doesn't offer a way to do that, but I'll be sure to pass this along as a feature request. I can't promise if or when that may be implemented though.

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

I'm not familiar enough with the Xcode build system to say confidently what the issue may be, but there's a post here about an issue that sounds like this: https://stackoverflow.com/questions/39588223/xcode-8-recompiling-complete-code-everytime I'll ask the team to review this though.

I just wrote this for this thread, but I'll make a note to post it on StackOverflow later. Thanks!

You don't need to use DbxRawClientV2. You should instead use DbxClientV2, as shown in the examples, e.g., here. Calling addFileMember would look like this: DbxRequestConfig config = new DbxRequestConfig("example"); DbxClientV2 client = new DbxClientV2(config, ACCESS_TOKEN); List<MemberSelector> newMembers = new…