52inc / Pulley

A library to imitate the iOS 10 Maps UI.
https://cocoapods.org/pods/Pulley
MIT License
2.02k stars 265 forks source link

Instructions unclear #331

Closed mredig closed 5 years ago

mredig commented 5 years ago

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 commented 5 years ago

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: https://github.com/Carthage/Carthage/issues/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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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.