Android & iOS: How to handle dependencies when building an SDK

Question

I'm currently working on an SDK which is available on both Android & iOS platform.

For Android, we list dependencies in our Gradle file and use Maven to provide the SDK (so our dependencies are listed in the .pom file).

For iOS, we use cocoapods to handle dependendies.

The problem is the following: * Our SDK use a dependency in version X * One of our client might use the same dependency but in version Y * Another client might also use the exact same dependency in version Z

So, this leads to our SDK potentially being broken on one of our client (if not both) because we ensure that it works with dependency X, but not Y and Z.

For now, the legacy code has simply imported source code of libraries causing this problem and namespaced it, such that it simulates we do not use the same library.

But in my opinion, this is not an appriopriate solution: we do not have latest fixes, it is painful to update, client has two times the library instead of one.

So, for now, I'm trying to think about a potential good solution, but couldn't find what I want on Google (maybe I'm not using the right keywords :/).

What I was thinking about was to provide support for a range of versions for each dependency. A bit like "if this method is here, execute it, otherwise, use that method of the previous version" (like selector respondTo on iOS). Then, the client should be able to use any version of the dependency at the condition it is in the supported range.

However, I don't know if it is the right way? Is there any other solutions?

Thanks :)

Answer 1

For android, there are two possible solutions, a build-tool based one, and an architectural one:

1.-If you build your library with maven, you can use the "provided" scope to force your library to get the dependencies from the container running it. That way, the dependency can be provided by the app consuming your library. Note that this will not help you if the dependencies are wildly different.

2.-Abstraction to the rescue! You can subdivide your project into the main library and plugin libraries. The main library will show the user every class an method and that will be the one they will call from their apps. Inside the main library, all classes will import every external SDK or dependency in an indirect form, a generic wrapper which can be either an abstract class or an interface, and use them that way. For example, maybe you are providing an enhanced facebook login UI. Then, instead of referencing the facebook SDK directly into your View, you will reference a facebookLoginInterface and call it. Then, you'll have a secondary project, facebookLogin41, where you will implement the facebookLoginInterface using the facebook sdk 4.1, and a second one, facebookLogin418, where you implement the same interface using the facebook sdk 4.1.8. Then, implement some sort of providing logic, like a Dependency Injection framework (Roboguice providers are a very good example), maven dependency scope (provided, for example), etc, to make the library instance the facebookLoginInterface. Finally, the client just imports both the main library and the secondary project needed and uses the main library.