Skip to content
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

Closed
mredig opened this issue Apr 20, 2019 · 5 comments
Closed

Instructions unclear #331

mredig opened this issue Apr 20, 2019 · 5 comments

Comments

@mredig
Copy link
Contributor

mredig commented Apr 20, 2019

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:

import UIKit
import Pulley

class PulleySub: PulleyViewController {
	
	required init?(coder aDecoder: NSCoder) {
		let storyboard = UIStoryboard.init(name: "Main", bundle: nil)
		let mainVC = storyboard.instantiateViewController(withIdentifier: "mainVC")
		let settings = storyboard.instantiateViewController(withIdentifier: "settingsVC")
		super.init(contentViewController: mainVC, drawerViewController: settings)
	}
	
	required init(contentViewController: UIViewController, drawerViewController: UIViewController) {
		super.init(contentViewController: contentViewController, drawerViewController: drawerViewController)
	}
}

(In interface builder, I simply have a solo UIViewController with which I set the class to PulleySub)

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.

@amyleecodes
Copy link
Contributor

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.

@mredig
Copy link
Contributor Author

mredig commented Apr 20, 2019

I don't think that link will help. I was able to make a PulleyViewController in IB just fine. I just couldn't connect the primaryContentContainerView and its sibling to the IBOutlets. All that the compiled framework gives is .h headers and, despite trying, I was not able to connect to the properties in there. When trying to run the app, it would crash from the primaryContentContainerView etc not being set and being a nil value.

Can you confirm for me that my understanding is correct that I'm supposed to connect the outlet in interface builder for primaryContentContainerView directly to the code included in this library? As in, in the PulleyViewController.swift class file?

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)

@amyleecodes
Copy link
Contributor

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”.

@mredig
Copy link
Contributor Author

mredig commented Apr 20, 2019

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. 👍

@mredig
Copy link
Contributor Author

mredig commented Apr 20, 2019

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.

@mredig mredig closed this as completed Apr 20, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants