Robert S.138 Collaborator | Level 9

Additional information: When it crashed I was still linking with an older version of OKHTTP3 (version 3.10.0). When I updated to version 4.12.0, the Dropbox OAuth v2 flow worked fine without a crash. There is no specific functionality in OKHTTP3 that I need, so I may still remove it just to be safe.

Even without a specific test for use of the deprecated protocols, there is one thing Dropbox could do to help us know if we have a problem with our latest version. In the e-mail that goes out to developers telling them that they detected "some activity" with the deprecated protocols, why not include something more…

Can you at least confirm that the following is sufficient for avoiding the deprecated protocols: In the Android version of our app, the build.gradle file under the app folder contains: dependencies { . . . . implementation 'com.dropbox.core:dropbox-core-sdk:3.1.5' . . . . } and in the iOS version of our app, all the files…

I received an e-mail from Dropbox warning that "your app(s) TuneLab Tuning Files have recently made calls to the Dropbox API using a deprecated TLS protocol version." I thought we had updated both our iOS and Android versions over a year ago. I suppose it is possible that some users of our apps have not updated in all that…

By the way, I tried to run this code without making any changes in the App Console, and the Auth.startOAuth2PKCE produced an error 400 in the browser. But after I went to my App Console and clicked "Migrate" (leaving all the permissions the same), then the Auth worked fine and my app works fine. So you really do have to…

**SOLVED** The main problem was that the Intel 64-bit architecture was not recognized by XCODE as on of the build architectures. That in turn was caused by the update to XCODE 12. Even though the architectures were properly indicated as $(ARCHS_STANDARD) in both the project and the target build settings, they were being…

In the meantime perhaps someone at Dropbox could at least try to add the SDK to a new skeleton project using XCODE 12. The test is to build for both the simulator and a real ARM device.

Is there a way to add the Dropbox SDK to an XCODE project that does not involve any 3rd party software like Carthage or CocoaPods just by copying source code directly? Even though the problem I need to debug in iOS 14 has nothing to do with Dropbox, if I can't even build my app for iOS 14 I can't do any debugging on that…

Here is the latest minimal failure example: Start XCODE 12.0.1: Select "New Project". Select "App". Project Name: "TuneLab3" Create. This skeleton program builds OK. Now to manually add Dropbox as a subproject (which also involves Carthage). Create Cartfile in project root with the following contents: #…

In addition to the problems with the Dropbox API installed with Carthage, I even tried making a new project with Cocoa Pods. In both cases, the XCODE 12 build process crashes whenever one of my application source files imports "ObjectiveDropboxOfficial.h". Has anyone successfully used XCODE 12 to build a project for the…

In addition to what Greg said, I would add that there is a very good reason for requiring that the user go through the explicit authorization process on a web page at least once. If there were a way to accomplish the same thing without ever sending the user to a web page, it would then be possible for malicious app code to…

The Dropbox support website still links to the 2.1.2 SDK documenation, which of course still refers to OkHttp3Requestor.INSTANCE. If you are on to version 3.x.x now, shouldn't your website link to the 3.x.x documentation? (Start at www.dropbox.com/developers and click on Java, then the Documenation tab, and then "full…

OK, I got this to work, but I don't really understand what is going on, so if anyone can verify that this is right, I would appreciate it. I replaced: DbxRequestConfig.Builder a = DbxRequestConfig.newBuilder("TuneLabPianoTuner/2.3"); DbxRequestConfig.Builder b = a.withHttpRequestor(OkHttp3Requestor.INSTANCE);…

My needs are actually simpler than that. I just need to know when it isn't going to work. Then I can display a message to the user explaining the problem. I can tell them to either install the Dropbox app or enable Safari. I don't really need the Dropbox API to try any heroics with a browser that is probably designed to…

Wait a minute. authorizeFromController is your API. I don't know what it translates into in terms of pure Apple functions. I can't very well take this question to an Apple forum unless I can present the problem using only non-Dropbox concepts. It is not obvious to me that authorizeFromController is equivalent to…

I also got that error, but it turned out that all my uses of DBError in SDK 1.0.11 were actually DBRequestError in SDK 2.0.6. When I changed all my declarations from DBError to DBRequestError, everything compiled fine. Is that the right thing to do? I was using DBError to do things like isInternalServerError,…

Thanks. I figured it out too. I just ran pod update and it is updating from 1.0.11 to 2.0.6.

How can I check and how do I update? (I am very new to CoCoPods).

That problem is close, but has one major difference. In their case the full recompile happens with every kind of build. In my case the recompile only happens when I build for release (using Archive). When I build for debug, the Dropbox library does not recompile. As I said it is a small issue since I am almost always…

Thanks, it seems to work. I thought it might be something like that. But starting from the official docs for uploadAndFinish, all I could see was that it returned type R. Where in the docs was I supposed to see that R was FileMetadata in this case?

Keith, I don't think there ever will be a mapping to API v2 for the Sync functions. That level of functionality just won't be provided anymore. In our app which also used the Sync SDK, we are changing the functionality at the user level. Our app will no longer have a mode whereby a cache of synced files in maintained.…

Stephen, Having worked a little more with the SDK and gotten more familiar with it, I don't think it needs to be changed. Having API that block carries its own problems of interruptibility, etc. It is only a couple of lines of code to add a custom wait for completion. As far as the locked flags, I see why your…

Thank you, Stephen, for all that work. I will study this and incorporate as much of this into my design as I can understand. There are a few simplifications I will make, though. In my application the download only takes place when a certain view controller is active and the user is involved, if only as an observer. Instead…

OK, I figured out how to make the API calls blocking. Here is my worker thread function, processWithRecursion (in pseudo-code): processWithRecursion( currentDirectory ) { set waiting = YES; //..a volatile, atomic variable call listFolder: currentDirectory, with completion block: { get list of entries; set waiting = NO; }…

I have been studying these API calls, and even with a custom queue, I don't see how to do what I want. First of all, here is the pseudo-code for what I have implemented in Android (omitting all error-handling), and what I want to do in iOS. It downloads all the files in Dropbox and runs in a single background thread - not…

What I need to do is copy an entire directory tree, one file at a time. The easiest way to do that is to write a method that handles one folder, and then make that method call itself recursively when a subfolder is found. But such code is not suitable for the UI thread, which must be event-driven and non-blocking. If I…

I think the confusion comes from my trying to persist the Access Token myself instead of letting DBKeychain do it. In the Android version, I don't think there was any choice. If we wanted the Access Token to persist between sessions, we had to store it ourselves in the app Preferences. But for the iOS version, it appears…

In the emulator I selected a different device, which causes the iOS to reboot. Then the error went away. So perhaps the exception was a side-effect of stoping the app with Xcode and starting it up again. But that leads me to wonder if there aren't some scenarios in real devices where something like this happens and an…

It is my understanding that Sync uses v1, and therefore it will cease to function on June 28, 2017. My app used Sync on both Android and iPhone. I have already changed my Android app to use Core API v2, which means I had to give up the background file syncing and caching and use only explicit and immediate uploads and…

Maybe it is the way I faked the invalid token. Instead of passing a real, but invalidated token, I passed "Z" + validToken to the "new DbxClientV2(requestConfig, DBaccessToken);" API call. So it has one more letter than the real token. And the message with that exception is "OAuth2 token is mal-formed". I'll bet that's it.