Need to see if your shared folder is taking up space on your dropbox 👨💻? Find out how to check here.
Forum Discussion
Solved
Short-lived token migration in Swift producing nil Client
I'm migrating an old Swift app to SwiftyDropbox 6.0.3 and short-lived tokens with refresh; our app needs offline access. But with the code changes, I'm getting odd behaviour -- the completion handle...
I think I've resolved it -- I'm still not sure why it was interfering with that URL scheme in the main program, but that may be down to the Group Container settings which lump the app and the Finder Sync extension together for communication purposes!
The source of the problem was that the Finder Sync extension was trying to connect to the socket on *its* main thread, and taking a full minute to fail. By moving the connection attempt off of the main DispatchQueue onto a low-priority one, the problem with Dropbox not being able to get through to the main program vanished.
Strange, but hey, if it works...!
Following from my previous update -- this is SwiftyDropbox 6.0.3 installed using CocoaPods, and Xcode 12.5 on Big Sur 11.4. But as I said, I'm now suspecting that there's something going on elsewhere in my app, blocking the dispatch queue which authorizeFromControllerV2 / handleRedirectURL is trying to use. Are there guidelines about what parts of the auth process should or shouldn't be called on the main thread?
Greg-DB
Dropbox Community Moderator
Dropbox Community ModeratorI don't believe there's any specific guidance with respect to threading for the authorization process. The official documentation for implementing the app authorization flow can be found here.
Here's a bit more on this. The problem seems to be a timeout that's causing the application to sit for up to one minute between me pressing "Allow Safari to open [my app]" after pressing the Allow button during the auth process, and the event actually being received in my code.
As far as I can tell, there doesn't appear to be anything else running in my app at all during that time, it's completely idling. But here's the weird bit -- my app has a FinderSync extension, as part of the same app group, which is trying to connect to the main application through a socket. (It's not succeeding, because my app doesn't start listening until after the Dropbox connection is in place.) But it keeps retrying for a minute before closing the socket... and after it closes, suddenly the response comes through from Safari to my handleGetURLEvent method.
Note that none of this happened with the old SwiftyDropbox 3/4 version! So I guess the next question is, how are the auth pages trying to send the message back to the main application, so that the kAEGetURL event is getting held up by either the app or the FinderSync handler in the same app group?...
- Greg-DB
The app authorization page in the browser connects back to the native app using a custom URL scheme, which the app sets in its plist file, from this step in the setup documentation. Specifically, it's the "db-<APP_KEY>" set in CFBundleURLSchemes under CFBundleURLTypes. (The Dropbox web page knows to redirect back to a URL using that URL scheme, which opens the app.)
I'm not familiar with Finder Sync extensions, but is there any reason it might be interfering with that URL scheme?
I think I've resolved it -- I'm still not sure why it was interfering with that URL scheme in the main program, but that may be down to the Group Container settings which lump the app and the Finder Sync extension together for communication purposes!
The source of the problem was that the Finder Sync extension was trying to connect to the socket on *its* main thread, and taking a full minute to fail. By moving the connection attempt off of the main DispatchQueue onto a low-priority one, the problem with Dropbox not being able to get through to the main program vanished.
Strange, but hey, if it works...!
About Dropbox API Support & Feedback
Find help with the Dropbox API from other developers.
