Doesn't have cocoapods support about lnpopupcontroller

[LeoNatan]

Right, the issue here is that this is a dynamic framework, and I have zero experience with CocoaPods with dynamic libraries. It used to be a big mess. If anything, I am more interested in Carthage support, as it is a much leaner solution.

[jameseunson]

Ah interesting, didn't realise. I respect your choice of Carthage. I'm still curious to see if it can be done, so I might do some research. Thanks for your fast response

[LeoNatan]

I am keeping this issue open for now. If you want to help me out, would like that. You can submit PR and I will merge.

[jameseunson]

Hey, managed to compile the .framework into a .a static library, which makes it easy to turn into a Cocoapod. The method of doing this involved adding a static library target to the LNPopupController project, and adding headers and sources in the correct parts of the build phases section.

I then used these commands to generate a static library:

xcodebuild -target LNPopupController-staticlib -configuration Release -sdk iphonesimulator9.0
xcodebuild -target LNPopupController-staticlib -configuration Release -sdk iphoneos9.0

lipo build/Release-iphonesimulator/libLNPopupController-staticlib.a Build/Release-iphoneos/libLNPopupController-staticlib.a -create -output build/libLNPopupController.a

I catted all your public header files into one file, which again makes it easier to create a Podfile. I'm also not familiar with the process of creating a cocoapod, but the Flurry pod seems like a good basis as it is distributed as a static library and accompanying header file. The spec for Flurry for iOS is here: https://github.com/flurry/Flurry-iOS-SDK/blob/master/Flurry-iOS-SDK.podspec If you like I can write a spec based on this next week. The specific flag Flurry uses to bundle the static library is detailed here: https://guides.cocoapods.org/syntax/podspec.html#vendored_libraries

And finally a screenshot of the library functioning in one of my apps, running from the compiled static library and header file: . Images are missing, but I'm sure I can work that one out.

Cheers,
James

[LeoNatan]

This is the one solution I do not want to support. 😄 Feel free to use it, of course, but going forward, a dynamic framework is the obvious way to go. One advantage is, as you said, images. Because dynamic frameworks are bundles of their own, they can have their own assets that are not merged into the main bundle. This is why I prefer Carthage in this regard.

[jameseunson]

Fair point 😝, it was educational for me anyway.

[LeoNatan]

Sure, that's quite the detective work, and thanks for it!

If I was to look into Carthage integration, would you be interested?

[jameseunson]

Sure thing, I've never used it before, but it's authored by Github so I'm sure it's good. If you add it, I'll definitely use it.

[LeoNatan]

Great! 👍

[jameseunson]

Hey,

Sorry to go on about this but I found something that is pretty relevant to your project, relating to CocoaPods and distributing a Framework. I was experimenting with a Firebase (https://www.firebase.com/) API over the weekend and integrated their client library as a CocoaPod into my test project.

I couldn't help but notice their CocoaPod Podspec is literally just a reference to their .framework file, bundled into a zip and placed on a CDN.

Their podspec is here: https://github.com/CocoaPods/Specs/blob/master/Specs/Firebase/2.4.0/Firebase.podspec.json

The "vendored_frameworks" entry points to the name of their framework, and the framework location is specified using the "source" entry and points to their CDN: https://cdn.firebase.com/ObjC/Firebase.framework-2.4.0.zip

Theoretically you could use their podspec as a template for your own?

This is the last I'll mention of this, I promise 😂

[funkenstrahlen]

To be honest: I do not know enough about Pods and dynamic frameworks to judge if a Pod of this framework makes sense or not. I respect your decision not to create a Pod.

However I would appreciate if you could improve the readme part about integrating this framework into an existing project. I struggle a lot trying to do that.

[LeoNatan]

@funkenstrahlen The included explanation is really all you need to do. Drag the project to your project, add it to Embedded Binaries in your target, and that should be it.

[LeoNatan]

Added Carthage support. Will not support CocoaPods.

[Urkman]

If you are interested to support Cocopods...
Just add a file with this name:
LNPopupController.podspec

And add this to the file:
Pod::Spec.new do |s|
s.name = 'LNPopupController'
s.version = '1.4.5'
s.license = 'MIT'
s.summary = 'A framework for presenting view controllers as popups of other view controllers.'
s.description = 'LNPopupController is a framework for presenting view controllers as popups of other view controllers, much like the Apple Music and Podcasts apps.'
s.homepage = 'https://github.com/LeoNatan/LNPopupController'
s.authors = 'Leo Natan'
s.source = { :git => 'https://github.com/LeoNatan/LNPopupController.git', :tag => 'v' << s.version.to_s }
s.source_files = 'LNPopupController//*.{h,m}', 'LNPopupController///*.{h,m}'
s.public_header_files = 'LNPopupController//.h'
s.private_header_files = 'LNPopupController/__/Private/.h'
s.resources = 'LNPopupController/*.xcassets'
s.requires_arc = true
s.ios.deployment_target = '8.0'
end

And you are all set...

If you somebody uses Swift:
Just add "@import LNPopupController;" to the Bridging header...

[iDevelopper]

Don't understand why this framework do not have Cocoapods support? I have read that is because of dynamic library, however Cocoapods support this, no?