Open chrisvanbuskirk opened 2 months ago
Thanks for writing this up and submitting a sample project! I'll ask the team to look into this.
I suspect effectively importing SwiftyDropboxObjC in the bridging header is causing some circularity when generating the bridging header, failing there. I don't immediately see anything I can do to alleviate this from our side.
I think you will need some kind of workaround on your side. Instead of importing SwiftyDropboxObjC
in ViewController.h
, you can forward declare the needed type, i.e., @class DBXDropboxClient;
there, then import SwiftyDropboxObjC
in the ViewController.m
file.
The consequence will be that you won't be able to access ViewController._dbxClient
from Swift code, you'll need some workaround. That could be: continue using a SwiftyDropboxObjC client and wrap it in your own type(s) or functions on ViewController and call that/those from Swift, or it could be to write an api layer in @objc-compatible Swift around a SwiftyDropbox client.
@julianlocke thank you for the detailed response. I can try the suggested workaround. Fortunately the client is in a manager which doing all the work. I will try it out.
@julianlocke the work around works just fine. In my testing so far of adopting SwiftyDropbox I've noticed that downloadWithPath does not call its progress block. However, uploadDataWithPath does indeed call its progress block.
@chrisvanbuskirk Thanks for the note! I'll ask the team to look into that as well.
I imported SwiftyDropbox into my project via SPM. Migrating from dropbox-sdk-obj-c and made necessary code changes, which worked.
It will work fine until you include a header file importing SwiftyDropboxObjC in a bridging header.
@import SwiftyDropboxObjC <- module not found
If the plan is deprecate dropbox-sdk-obj-c it would be ideal to fix this to work with hybrid objc/swift projects. I haven't tried it in cocoapods which is not a solution I want.
I've included a sample project. dropbox.zip