Stephen C.14 Dropboxer

Steve, an `uploadsInProgress` method has been added to the batch upload logic in the latest version of the SDK. Let us know if you have any problems with it.

Hi Mark, thanks for bringing this up. Unfortunately, based on the SDK design, there isn't a great way for the SDK to expose file move errors to the end user, without seriously cluttering up the interface. If your solution of manually moving the files to a temp location is feasible for you, then I'm inclined to hold off on…

Hey Mark, check out the latest version of the SDK, v.3.0.8. It is now thread-safe. You should be able to make requests from any thread. Let me know if you run into any issues!

Thanks for letting me know. I looked into making the Obj-C SDK threadsafe, and I actually don't think it will require much work on my end, so I'll go ahead and do that, and put out a new version later today. If you wouldn't mind, try it out, and see if you run into any threading issues. I'm pretty sure I accounted for…

Thanks for reaching out. Currently, the SDK is not thread safe. There is an implicit assumption that all requesting is done serially from the same thread. Response code is executed serially on whichever thread (NSOperationQueue) you supply, for the given request. As you pointed out, the networking layer is implemented…

Thanks for reaching out. Supplying `include_deleted` to a metadata endpoint should return the correct deleted metadata. However, if you just recently deleted the Dropbox object, there can be a small delay (should never be more than a minute) where the deleted metadata is populated. Have you tried waiting for a small period…

Thanks for letting us know, Steve. This should be updated now! Let us know if you run into any issues migrating.

Unfortunately, at the moment, we don't have any updates to share here – apologies!

Thanks for reaching out, Ben. Seems like the answer on StackOverflow is probably more than I could offer you. As the reponse there says, the best fallback approach would be to have a has-a-filename-extension check to manually catch all your bundle types.

Hi Robert, I looked into this issue. It's going to be hard on our end to detect this case, but what you can do is check the success of the `openURL` call you make in the closure that you pass the SDK. For example: [DBClientsManager authorizeFromController:[UIApplication sharedApplication] controller:self openURL:^(NSURL…

Thanks for bringing this to our attention, Kieth. I've gone ahead and put out another version of the SDK (1.1.3). Would you mind pulling it and seeing if the problem persists? Let us know – thanks for your patience!

@Dennis B.: Sorry about the issues. The .xcodeproj in the main repo wasn't set to Swift 3.0 for the macOS target. The problem should be fixed now. Try re-pulling from Carthage with the following Cartfile: # SwiftyDropboxgithub "https://github.com/dropbox/SwiftyDropbox" ~> 4.0.4 and the following command: carthage update…

@Robert S.: That makes sense! There certainly is a balance to be struck between simplicity of the code and performance. Good luck with your implementation, and please reach out if you run into anything else or have any more general feedback about the SDK.

No worries! Hopefully it will be of some help. I would just make sure that you weigh whether it's important to track the response `DBTask` objects that you receive back, so that if you're downloading a lot of files from a folder, you have a way of canceling them all at once (if you feel like that's important). As far as…

@Robert S: I wouldn't recommend using `sleep` like that. I'd instead maintain references to each task object and then `cancel` each task object when the user cancels. I took a bit of time and wrote up what a solution might look like. It took me longer than I thought, which might be an indication that the SDK needs richer…

Thanks for reaching out. Are you looking to specify a custom queue on a route-by-route basis? If you're looking to simply set a custom queue for all API calls, you can do that by supplying a custom `DBTransportClient` with a custom `delegateQueue` when you setup your app. You can read about it more on the GitHub tutorial…

@Mark L.: No worries, we're constantly trying to improve the SDK, so it's really helpful hearing your feedback. As far as the issue you're having, you can fix it by making a single call to `DropboxClientsManager.unlinkClient()` in your code. As of the latest version of SwiftyDropbox, we've removed these cumbersome assert…

@Stewart L.: Thanks! It's fixed now :)

@Mark L.: Sorry for all the trouble you've had with adding the subproject manually. I went ahead and update the README to be way more detailed and clearer about manually adding a subproject. I know you've had a frustrating experience up until this point, but if you'd be willing to give it another shot with the SDK, we'd…

@Mark L.: Thanks for your patience – we're really prioritizing this and should have a Swift 3 / Alamofire 4 fork out very soon (along with a bunch of other updates). I'll ping this thread when it's out.

@Clifton L.: Ok, let's try a few things. I think it might be related to XCode's source control integration. Please try the following: Navigate to the SoureControl menu item > Refresh status and see if the missing file error continues. In one of our updates, we renamed the Auth.swift file to OAuth.swift, so that might have…

@Clifton L.: These issues can be tricky to debug. Often they're transient – would you mind confirming that you've done a clean build on your project (cmd+shift+k) and reset your pods (`rm -rf Pods/; rm Podfile.lock; pod install`)?

If you're trying to build an app for clients to upload files to one Dropbox account (say your personal account), then there is no client-side solution that will allow clients to securely upload directly to your Dropbox. Your access token will always be exposed client-side. If you want to use your personal Dropbox account…

Thanks for reaching out. I'm not totally sure I follow your question. You can share files individually by creating a shared link via /create_shared_link_with_settings (https://www.dropbox.com/developers/documentation/http/documentation#sharing-create_shared_link_with_settings), or if you want to share all files within a…

Unfortunately, at this time, there is no way to use the Dropbox API to create file requests and add members. You can only do so manually, via our web UI.

Yes, we are aware that a sizable portion of Android users still use versions < KitKat (4.4), but unfortunately we are not able to guarantee support for them with our SDK.

Yes, that is correct. The minimum supported Android version for the v2 SDK is KitKat (4.4), meaning your app cannot support both the SDK and versions of Android < KitKat (4.4).

Yes, dropbox-core-sdk-2.1.1.jar is the appropriate SDK to use with your app to make calls to API v2. The minimum compatible version of Android for this new SDK is KitKat (4.4). Migrating from using an API v1 SDK to an API v2 SDK will require some refactoring in your code. This migration guide offers an overview of the…

Shared links by design expose as little information as possible about the internal structure of a user's Dropbox. In the example that you provided, the first link to the "sample" folder was created to share only the contents of that directory and subdirectory, and not to reveal anything about the super-structure that it's…

I'm sorry that the Deprecation Guide was not more helpful to you. The Guide is not meant to totally comprehensive, platform-specific migration guide, but is instead intended to give you a qualitative sense of how API v2 differs from API v1. To answer your question, there is no easy way to toggle seamlessly between API v1…