Add OvershareKit podspec

[jhersh]

I've started on an OvershareKit podspec as per #1.

This podspec lints cleanly with pod spec lint. There's a few more things to do:

• Push a tag to OvershareKit, update tag ref in the podspec
• Add your email addresses to the podspec

[jhersh]

So I went all-out with dynamic subspecs :)

• Added a Providers folder and moved most of the third-party providers there
• Podspec file now dynamically generates subspecs for each provider, so you can pick and choose only the providers you're interested in
• Each subspec defines a macro, e.g. OVERSHARE_POCKET, and I've added flags to some Overshare files to check for the presence of certain providers so they still run if the provider is not present
• Moved categories into Overshare Kit/Additions

This has grown into something of a major change and I understand if you want to take some time to look over it. Another consequence is that, while subspecs make it very easy to use OvershareKit with Cocoapods, you'd need a bit more work to use OvershareKit outside of Cocoapods: a simple header file that defines all macros generated by the subspecs.

[ghost]

oh… so overshare-kit works with iOS 7 only?

[jhersh]

Not necessarily, I just picked a number based on the screenshot :) @jaredsinclair perhaps can clarify minimum OS

[ghost]

awesome :) i can't wait to see overshare-kit in the cocoapods repository. good job :)

[jhersh]

Here's a sample project using Overshare with cocoapods. Clone and run cd OKTest && pod install: https://github.com/jhersh/overshare-kit/tree/m.cocoapods-test

[ghost]

if you change the required version to iOS 6.0 I can test it in my projects.

Like this:
pod "OvershareKit", :git => "https://github.com/overshare/overshare-kit.git", :commit => "87ce156f97bc726ab749c9f14cef3821f96ff16b"

But I get an error because I am supporting iOS 6.0 in my projects.
[!] The platform of the target Pods (iOS 6.0) is not compatible with OvershareKit (0.0.1) which has a minimum requirement of iOS 7.0.

[jhersh]

OK, podspec now using iOS 6

[ghost]

Thanks man!

[brittonmobile]

It won't work in iOS 6. It uses among other things: NSURLComponents, UIButtonTypeSystem, -[NSString stringByAddingPercentEncodingWithAllowedCharacters:], +[NSCharacterSet URLQueryAllowedCharacterSet], -[NSData base64EncodedStringWithOptions:], etc.

[justin]

OvershareKit requires iOS 7. We built it for the future, not the past.

• j

On Nov 2, 2013, at 20:21, brittonmobile notifications@github.com wrote:

It won't work in iOS 6. It uses among other things: NSURLComponents, UIButtonTypeSystem, -[NSString stringByAddingPercentEncodingWithAllowedCharacters:], +[NSCharacterSet URLQueryAllowedCharacterSet], -[NSData base64EncodedStringWithOptions:], etc.

—
Reply to this email directly or view it on GitHub.

[jhersh]

Updated podspec to indicate 7, squashed

[ghost]

Got it!!! that is both bad news and good news. building for the future is good ;)

I suggest that you add that information to the main page so that everyone knows overshare-kit requires iOS 7.

[justin]

We are OK with having the ability for people to import and use OSK through Cocoapods, but not at the expense of rearranging the entire project and making it heavily dependent on people having to use Cocoapods. Neither Jared nor I use it in our workflows.

Is there a way to do this without having to adjust the existing project implementation?

[jhersh]

I removed the Additions folder, so that's a good number fewer files impacted. I'll look into further minimizing the impact

[jhersh]

With this new OvershareKitProviders.h file in non-Cocoapods projects (not included in Cocoapods projects -- this file is not part of the podspec), there shouldn't be any functional difference in OvershareKit with or without cocoapods.

There is admittedly still the Providers folder and a bunch of macros. Closer?

[jaredsinclair]

@jhersh I don't understand why there are #ifdefs wrapping Twitter, 1Password, and other activity types. Only the ADN and Pocket activities are dependent upon third-party repositories. None of the other types have dependencies. What are you trying to accomplish?

[jhersh]

@jaredsinclair It's less about dependencies and more a means for the developer to pick and choose only the providers she wants to include. For example I sure do love me some 1Password, and included a 1Password search feature in an app of mine, but I don't think anyone ever used it. Nor do I think my users would know the first thing about ADN.

Ultimately the developer should know her users best, and subspecs let her make the judgment call about which to include. The full suite of OvershareKit providers, while very impressive, is too much for some uses.

[jaredsinclair]

There's already an API for this. Check out the header for OSKActivitiesManager. You set permanent exclusions by activity type: markActivityTypes:alwaysExcluded:

[jhersh]

Yup, you're correct. I guess subspecs could be the difference between excluding activities and excluding activities without requiring their dependencies.

[jaredsinclair]

Also, those 1Password activities won't appear unless the user actually has the app installed. If somebody has the app, they'd probably want to use it, rather than applying a blanket policy that nobody should see it. :-)

[jaredsinclair]

Same with OmniFocus, Things, and any other URL schemes yet to come.

[jaredsinclair]

"Yup, you're correct. I guess subspecs could be the difference between excluding activities and excluding activities without requiring their dependencies."

I don't understand what you mean. Our intention is to require those dependencies, plain and simple. We'd like to provide the option to either use traditional git submodules, or Cocoa Pods, to manage those dependencies. But we're not keen on peppering the library with #ifdefs to exclude activity types.

[jhersh]

Our intention is to require those dependencies, plain and simple.

Thanks, I think that's what I didn't understand until now. I'll take another look at the podspec

[jaredsinclair]

Ah. Thanks. Sometimes I leave out important ______ in the middle of a thought. Bad habit.

[jhersh]

New podspec now posted with no project changes. It requires the ADNLogin and PocketAPI pods.

To do remaining: push a tag, add tag and your emails to the podspec.

[brianeunilkim]

Looking forward to using Overshare Kit via CocoaPods!

[patoroco]

+1 waiting for Cocoa Pods oficial repo. Meanwhile I copy your podspec to my "private" repo: https://github.com/patoroco/personal-specs

If you want to use easily this podspec from cocoapods, simply add my repo to your cocoa executing:

pod repo add patoroco-specs git@github.com:patoroco/personal-specs.git

Thanks for your podspec! :)

[Heinemark]

That's brilliant @patoroco, thanks!

[Heinemark]

Getting quite a lot of errors when importing OvershareKit.h though. Should I do something more than adding the pod?

[jhersh]

@Heinemark Pods don't have modules enabled by default. You can either enable modules manually in your Pods project or use the new podspec I just pushed, which enables modules via compiler flag.

[Heinemark]

@jhersh Thanks! It was the main project that had that setting set to NO. Apparently it's now set to YES by default in projects created in xcode 5 and later.

[calimarkus]

please add official pod support!! 👍

[jhersh]

Bump :) @jaredsinclair

Here's all you need to do to support cocoapods in OvershareKit:

• Merge this PR, or one like it
• Push a tag to OvershareKit
• Add that tag and your emails to the podspec file
• Push the spec to the Cocoapods specs repo. I'm happy to do this for you once the spec is merged

[jaredsinclair]

@jhersh

1. So just to confirm, the latest commit at (https://github.com/jhersh/overshare-kit/commit/7f45cb0fab4518fed88506cbc591458ea6aa117e) does not require Xcode project changes? It's just the pod spec file that specifies the required dependencies?

2. You mean a git tag, correct?

3. See Add OvershareKit podspec #2.

4. Sweet, we appreciate all your time on this.

[patoroco]

Thanks @jaredsinclair 👍

[jhersh]

@jaredsinclair

1. Correct - the only change to the repo is the addition of this .podspec file.

2-3) Yes, a git tag. I recommend http://semver.org/ (and therefore a first tag of 0.0.1) but you can pick a naming scheme that works for you

Give me a minute to squash and rebase on master then you're all set

[jaredsinclair]

@jhersh I merged your podspec, tagged the up-to-date merge with 1.0.1. If everything looks good to you, we'd appreciate you pushing our spec to the specs repo.

[jhersh]

Thanks @jaredsinclair! We're really close. Some minor final bits here: #7

[patoroco]

I remove spec in my personal Cocoa Pods Specs repo. Thanks @jhersh!