Use external dependencies from CocoaPods

[eunikolsky]

ConnectSDK has a number of dependencies, that are currently integrated as source code in the project: https://github.com/ConnectSDK/Connect-SDK-iOS#credits. Considering #135, it would be much better to use CocoaPods to manage them.

A couple of points to consider:

_0. Some of our users may not use CocoaPods => they will have to download all those dependencies manually (now Google Cast only).

_1. It is possible that our SDK and an app using the SDK may depend on different major versions of a library. That results in a conflict of duplicated symbols.

http://stackoverflow.com/questions/23770105/solutions-for-using-different-versions-of-a-library-with-cocoapods-specifically
http://pdx.esri.com/blog/2013/12/13/namespacing-dependencies/
http://stackoverflow.com/questions/11512291/prefix-static-library-ios/19341366#19341366
http://atastypixel.com/blog/avoiding-duplicate-symbol-issues-when-using-common-utilities-within-a-static-library/
http://atnan.com/blog/2012/01/12/avoiding-duplicate-symbol-errors-during-linking-by-removing-classes-from-static-libraries/
http://blog.sigmapoint.pl/avoiding-dependency-collisions-in-ios-static-library-managed-by-cocoapods/

_2. It seems only SocketRocket library is modified in our project. That dependency cannot be extracted to CocoaPods. However, it may be a good time to replace it: #134

[sergiou87]

For (1) I can only think in relaxing the version requirements (not specifying the patch version, just minor.major versions, for example) in both sides (library and main project/other libraries) when possible. And, of course, hope that everyone is using Semantic Versioning correctly 😆

Regarding (2), if #134 is a lot of work, meanwhile you can create a Connect-SDK-iOS-SocketRocket pod and depend on it until a proper replacement is found. In my app I'm doing that with ConnectSDK (with the contents of #135) until this problem is fixed 😅

[sergiou87]

Another issue we're having, somehow related to this, is having a mix of pods and submodules. I think this is Cocoapods fault because it's not able to manage submodules correctly, but it's a problem anyway 😕

Under some circumstances, Cocoapods deletes all files of the pod coming from submodules and we have to delete Podfile.lock and run pod install again to make sure it clones submodules and keeps them.

Would it be possible to move both submodules (core and google-cast) to the main project? Their dependencies are already managed in the main project podspec file, after all.

[eunikolsky]

Under some circumstances, Cocoapods deletes all files of the pod coming from submodules and we have to delete Podfile.lock and run pod install again to make sure it clones submodules and keeps them.

I have never seen this behavior. Can you provide steps to reproduce it?

[eunikolsky]

Would it be possible to move both submodules (core and google-cast) to the main project? Their dependencies are already managed in the main project podspec file, after all.

Yes, it should be possible (using targets in the Xcode project), we need to discuss the pros and cons of that decision, and find a way to do the same with the Android ConnectSDK. That should be supported using gradle flavors, but what about Eclipse support?!

[eunikolsky]

For _0: we may switch to CocoaPods and then commit the Pods/ directory, so that our users will automagically get the dependencies even if they don't have CocoaPods installed. Apparently, this directory should be committed in both Full and Lite projects.

[eunikolsky]

For _1: another suggestion in to consider https://github.com/cocoapods/cocoapods-packager plugin