search

ConnectSDK / Connect-SDK-iOS

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

Better modules system #165

Open eunikolsky opened 9 years ago

eunikolsky commented 9 years ago

We currently have two projects (Full and Lite) and three submodules (core, google-cast, and samsung-multiscreen). Five repositories! As we're adding more modules, it'll get harder to maintain. Plus, what if our users want WebOS, DLNA, Cast, and Multiscreen support only? Either remove classes from Full version, or add modules manually to Lite version.

Here's a suggested better solution: Use one project and one repository for everything, and define targets for different platforms. That is, core (analogous to current Lite) would include WebOS, Netcast, smth else; roku would build Roku-classes only; airplay would build Airplay support only; etc. Each of them produces a static library and a set of headers (or a framework), and the user can link core, cast, and roku libraries to their app, getting only those platforms. Effectively, that's how CocoaPods works now. It would be easy to define subspecs in our podspec.

Check:

  1. how easy it's to include these modules into a real project;
  2. how to organize tests.

It should be possible to do the similar thing on Android with gradle's flavors.

eunikolsky commented 9 years ago
  1. Should the ZeroConfDiscoveryProvider be in core or AirPlay module, considering it's currently used in AirPlay only?
  2. If we separate Netcast and DLNA modules, how to do that properly? Consider Netcast is partially dependent on DLNA.
eunikolsky commented 9 years ago

For extra flexibility and improving build times, all third-party frameworks (GCDWebServer, XMLWriter, etc.) could be extracted into their own static libraries.

eunikolsky commented 9 years ago

A PoC project is available here: https://github.com/ConnectSDK/Connect-SDK-iOS/tree/poc/165_better_modules

eunikolsky commented 9 years ago

The ConnectSDKDefaultPlatforms.h file would have to include all supported platforms. Currently, the DiscoveryManager silently ignores missing classes. We can change it to log a note that this class is not available, you may want to compile extra modules.

eunikolsky commented 9 years ago

We can merge submodules back into the main repo saving the history with this tip: http://stackoverflow.com/a/23328223/635603 !

eunikolsky commented 9 years ago

An example of how such a system can work is the ShareKit library project. And here is the description: https://github.com/ShareKit/ShareKit/wiki/Granular-install