-
Notifications
You must be signed in to change notification settings - Fork 265
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Instructions unclear #331
Comments
Carthage and IBOutlets don’t play well together because of how dynamic frameworks work. Depending on your setup, you may be able to get it to work following this: Carthage/Carthage#1312 However, ultimately it’s an issue with Carthage and not something I can really do anything about. We recommend CocoaPods for this (and many other) reasons. |
I don't think that link will help. I was able to make a Can you confirm for me that my understanding is correct that I'm supposed to connect the outlet in interface builder for I know this isn't exactly the place to do so, but since GitHub doesn't have dm's, do you mind sharing some other reasons you prefer cocoapods to Carthage? (I've done a little research comparing and concluded that I personally prefer the philosophy of Carthage) |
Yes, the container view should be able to be directly connected to that outlet. Checkout the sample project for an example. The primary benefits are: a predictable & supported project integration, compiled with the same compiler version at the same time as the rest of your project, and not checking in compiled code to version control. This link has a good overview: https://reallifeprogramming.com/carthage-vs-cocoapods-vs-git-submodules-9dc341ec6710 Carthage makes a “dumb” compiled framework and leaves project integration to you. As you’ve noticed with this issue, that leaves a lot to be desired. Correct compiler flags aren’t managed, not every feature works, system framework links aren’t managed, etc. Its much more prone to error and things not working correctly and when things don’t work the available support is essentially non-existent because every issue is case/library specific. CocoaPods eliminates most/all of these issues. There’s nothing inherently wrong with Carthage. It works, if you have a preference for standalone dependencies you can manually manage them that’s great. But, things often don’t work right or require a lot more manual intervention. For someone maintaining a library, trying to troubleshoot someone’s specific Carthage setup & integration is virtually impossible. CocoaPods “just works”. |
Coincidentally, that's the exact article that I found previously that helped me decide to use Carthage over CocoaPods! Maybe my views will change as I gain more experience. :) Thanks for your assistance. 👍 |
Oh right - for the issue at hand... I guess if there's nothing to be done, I'll go ahead and close it. However, maybe there should be a note in the readme warning about this issue? I'll let you decide. |
In the how to use section, I can only assume the interface builder instruction to
Connect the container view for the primary (background) content to the outlet named primaryContentContainerView.
is for the manual installation (and maybe cocoa pods?). However, with carthage, I can find no way to connect interface builder to the code as suggested (This could, perhaps, just be a shortcoming on my part, but I doubt I'd be the only one).On the other side, doing it all programmatically, it's easy enough to do that once the first view controller is shown, but I don't know (and I doubt it's common knowledge) how to show your first view controller programmatically.
What I ended up doing was subclassing
PulleyViewController
and using a combo of IB and programmatic like this:(In interface builder, I simply have a solo
UIViewController
with which I set the class toPulleySub
)I don't know if this is a good idea or if this would be somehow compromised in the future. It feels clunky to me.
The text was updated successfully, but these errors were encountered: