Make it easier to configure without modifying pulled SHKConfig.h

[scompt]

My codebase is compiled to produce 3 apps (same "network", different sites). For each of these apps, I want to have a different SHKConfig.h for each of these app. That's easy enough to do with an extra build phase, but it also requires modifying or changing the SHKConfig.h that comes with ShareKit. It'd be great if there was a way to avoid this so that my pull can stay clean.

[treelinelabs]

Using a delegate for this would be a natural thing to do.

[chrissearle]

Was wondering about this from a different start point.

My codebase is publicly available. I don't really want to put my keys on github ;) Wondered about using a plist to hold keys - much easier to hold a plist outside of change control than a class

[scompt]

I've implemented this in my fork and created a pull request. I used a delegate, as suggested by treelinelabs. Take a look at it and let me know what you think. It should take care of your use case as well, chrissearle. You'll just need to create an SHKConfigurationDelegate instance (probably by extending DefaultSHKConfigurationDelegate) and get the values necessary from a plist.

[chrissearle]

Yes - that sounds OK. Will have to take a look.

[nzhuk]

Any progress on this issue? Making ShareKit configurable at runtime instead of compile-time would simplify Xcode project configurations a lot in some special cases.

[scompt]

I've been using the code in my fork in a number of published apps. I doubt it will be pulled into the master any time soon, so your best bet would be to use my fork or integrate the commits into your own.