ConnectSDK / Connect-SDK-iOS

iOS source project for Connect SDK
Apache License 2.0
174 stars 136 forks source link

Use external dependencies from CocoaPods #136

Open eunikolsky opened 9 years ago

eunikolsky commented 9 years ago

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 https://github.com/ConnectSDK/Connect-SDK-iOS/pull/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: https://github.com/ConnectSDK/Connect-SDK-iOS/issues/134

sergiou87 commented 9 years ago

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 :laughing:

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 :sweat_smile:

sergiou87 commented 9 years ago

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 :confused:

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

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

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

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

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