We are aware of the issue with the badge emails resending to everyone, we apologise for the inconvenience - learn more here.
Forum Discussion
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...!
Greg-DB
Dropbox Staff
Dropbox StaffI just gave this a try by setting up a new macOS project with your code snippets here, and it worked successfully for me. It got to "handleGetURLEvent: Success! User is logged into Dropbox.".
Can you let me know what versions of Xcode and macOS you're using? Also, what method did you use to install the SwiftyDropbox library?
The authorizeFromControllerV2 method automatically requests "offline" access.
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
I 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?...
About Dropbox API Support & Feedback
Find help with the Dropbox API from other developers.
