Android & iOS: how to handle dependencies when creating SDKs

Question

I am currently working on an SDK that is available on the Android and iOS platforms.

For Android, we list the 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 dependencies.

The problem is this: * Our SDK uses a dependency in version X * One of our clients can use the same dependency, but in version Y * Another client can also use the same dependency in version Z

Thus, this leads to the fact that our SDK can be split into one of our clients (if not both), because we guarantee that it works with dependency X, but not with Y and Z.

At this point, the legacy code simply imported the source code of the libraries causing this problem, and the names were put into it to simulate, we do not use the same library.

But, in my opinion, this is not an approximation solution: we do not have the latest corrections, it is painful to update, the client has two libraries instead of one.

So, at the moment I'm trying to think of a potential good solution, but I can’t find what I want on Google (maybe I don’t use the right keywords: /).

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

However, I do not know if this is correct? Are there any other solutions?

Thanks:)

Answer 1

There are two possible solutions for android: one based on a building tool and an architectural one:

1. If you create your library using maven, you can use the "provided" area to force your library to receive dependencies on the container used. Thus, a dependency can be provided by an application using your library. Please note that this will not help you if the dependencies are very 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 each class method, and it will be he who will call from his applications. Inside the main library, all classes will import each external SDK or dependency in an indirect form, a common shell, which can be either an abstract class or an interface, and use them in this way. For example, perhaps you provide an advanced facebook login interface. Then, instead of linking to the facebook SDK directly in your view, you will link to facebookLoginInterface and name it. Then you will have an additional facebookLogin41 project, where you will use facebookLoginInterface using facebook sdk 4.1, and the second facebookLogin418, where you will implement the same interface using facebook sdk 4.1.8. Then implement some kind of rendering logic, such as the Injection dependency infrastructure (Roboguice providers are a very good example), the maven dependency area (provided, for example), etc., to make an instance of the facebookLoginInterface library. Finally, the client simply imports both the main library and the required secondary project and uses the main library.