I built a library that does some network requests with Retrofit. Retrofit is included in the library as a JAR file.
I want to ship the library as .aar file.
The host app that will consume the .aar file will need to have Retrofit too since it needs to do some network requests.
What the host app should do?
Use the Retrofit library of the .aar file?
I've tried that and is
working, the problem is that doesn't sound like a maintainable solution
since the host app will be tied to the Retrofit version inside the
library.
Include another version of Retrofit?
I've tried that and I'm getting errors when I compile the host app since I have multiple versions of the Retrofit files. e.g:
More than one file was found with OS independent path 'okhttp3/internal/publicsuffix/NOTICE'
Is there any other solution?
I read that I can use the transitive option but if I do that the library will be dependent from the Retrofit version of the host app right?
Using the transitive option should be the best from my point of view.
The library is not dependent on the host app but the host app is dependent on the library. Your library will still use the version of Retrofit which you implemented inside the library.
By using the transitive option you are just making sure that the version of retrofit that is being used inside the Library is not being utilized by the host application.
Related
I'm building an Android Library and I would like some of its features to be downloaded only on-demand, as dynamic feature modules.
Is it possible to use Dynamic Delivery (from Google Play Core library) in an Android Library project?
I tried adding dynamicFeatures = [':my_dynamic_feature'] to my Library project's build.gradle, but when I try to do a Gradle sync, I'm getting the following error:
Could not set unknown property 'dynamicFeatures' for object of type com.android.build.gradle.LibraryExtension.
For this reason I suspect that Dynamic Delivery is only supported for 'com.android.application' but not for 'com.android.library'.
Can someone confirm whether this is supported or not?
Or at least planned for a future release of Play Core library?
Thanks!
Yes, currently it can only be used from the application class.
If you want to design your library in a way that it can later support a dynamic feature, you can move the dynamic feature related code to a separate library, let's call it DFLibrary.
Instead of directly calling the DFLibrary methods, you can use reflection.
Now, any client that wants to use your library and the DFLibrary but does not want to handle dynamic feature installation can include the dependencies of both your library and DFLibrary.
In case the client wants to use DFLibrary as a dynamic feature module, it can itself create a Dynamic feature module and include the DFLibrary dependency in it and then handle the downloading of that dynamic feature module.
I am looking into a way of creating a dependency library structure for my current project, where I create a core library dependency then use addition dependencies to add functionality automatically, however, I am aiming for a solution where my additional dependencies to not require in the inclusion of the Core library. Class objects within the additional dependencies with have access and use code that is located within the Core library (for example, an abstract class or interface).
I have seen an example of this with Ironsource, an advertising platform, if the developer wanted to, for example, add facebook adverts to their project, they would need to add the following dependencies in Gradle.
implementation 'com.ironsource.sdk:mediationsdk:6.9.1#jar'
implementation 'com.ironsource.adapters:facebookadapter:4.3.4#jar'
However, if they remove the main mediation SDK, the facebookadapter SDK no longer works as it is missing a class it is using within the mediation SDK. but instead returns an Unresolved Superclass error, as the superclass is only found in the mediationsdk dependancy.
My question is how did they do this? How did they use code in the facebookadapter(additional) that is only available in the mediationsdk(Core) library? and how can I replicate this dependancy style?
I have tried having both my core and additional libraries have the same package information but to no avail.
As far as I got your question correctly, you are interested in how Library B can use a class that shipped by Library A without including that explicitly. That is basically a difference between implementation and api in gradle dependencies specification, the first one does not include the dependencies transitively into your build. So when you develop Library B, and have Library A attached as implementation, it's not gonna be included into build artifacts, so consumer should provide it explicitly.
A common example of this approach is Retrofit or OkHttp, many 3rd party SDKs use them internally, but they don't want to ship them as built-in dependencies, so they do ask consumers to provide them.
So most likely, they just use implementation to locally resolve the ABI, but don't ship it inside of each com.ironsource.adapters:* module because it will be shipped many times then.
More information about different compile options:
https://developer.android.com/studio/build/dependencies#dependency_configurations
I am working on writing an SDK for a client. Part of the SDK requires me to interface with a good 20-30 endpoints. How I have always done this in the past is simply used Retrofit and OkHttp for the API interface. I recently discovered, however, that you cannot use 'nested' library references within a library.
My question is, how do I go about using Retrofit in this current library I am making so that it can be used on other devices? Do I just need to clone the repo, copy the code into my project and go from there? Or is there a simpler method?
Thanks all.
Your can use maven transitive dependency.
Or AAR have no problems with nested jar files. From documentation
A library module can include a JAR library
You can develop a library module that itself includes a JAR library; however you need to manually edit the dependent app modules's build path and add a path to the JAR file.
I use this approach for okhttp.
An unreleased android library I am working on has a third party networking library in it - OkHttp in this case.
Projects that use this library as a dependency also are now able to create objects with that networking library.
Can I limit or disable access to the networking library contained within my library?
You could make the dependency transitive however if your code hits the missing code inside their app it will fail ClassNotFound or MethodNotFound
dependencies {
compile('com.squareup.okhttp3:okhttp:3.2.0') {
transitive = false
}
}
Short of that once the code is packaged with your lib it's available to anyone who wants to use it from your lib.
This still won't solve the problem as you would like but you could use proguard to rename the okhttp classes. Users of your lib could still call the okhttp classes but they would be renamed by proguard to something like a,b,c,...
What you want to do is shade the dependency. Here's a description from a blog post about shading dependencies in Gradle:
To Shade a library is to take the contents files of said library, put
them in your own jar, and change their package.This is different from
packaging which is simply shipping the libraries files in side your
own jar without relocating them to a different package. The term
fatjar is commonly used to refer to jars that have the application as
well as its dependencies packaged or shaded into them.
It's easy to do for smaller libraries. I could image it might be difficult for a large library like OkHttp. You can do it manually by simply copying the files into your project and changing the package. There are also some scripts that will do it automatically. They usually use Jar Jar Links.
Normally be default you don't have the dependencies like that:
compile rootProject.ext.okhttp
compiled in your jar only your sources are. So OkHttp classes will not be in your lib.
I have exactly the same case. I use gradle to build and upload to maven.
You can check here
So if your intention is to have the exact dept version in the package and to be hidden you just need to include it in you project as a module and to change some things like the package of OkHttp to avoid conflicts and also the access to currenly public okhttp members. OkHttp is using Okio so you may want to privatize it too.
Note that this kind of shadowing + hiding functionality of the shadowed class can be useful for framework dependencies(ensuring all depts in runtime available) but it is increasing the size of your libs and will not be the best option for apps using your lib as they anyway ensure packaging required depts in the apk.
Generally we download module from git or any version control, store it locally and add this as a module dependency. So everytime if there is any changes on module, I have to pull and update the existing one locally.
Is there any way to add the Module direct from git/svn and if there is any changes(commit) on module, it will reflect automatically?
To include third party libraries into your application, without having to add the source to your version control, you can use third party dependencies.
For example, the Picasso Library from square (http://square.github.io/picasso/) can be loaded in with compile 'com.squareup.picasso:picasso:2.5.2'. This goes in the dependencies block in your build.gradle config.
To update to a later version, you simply change the 2.5.2 to the required version number.
This is also where you can (or might be doing already) include Google Play Services, and the Android Design and Support libraries.
For more information, see here http://tools.android.com/tech-docs/new-build-system/user-guide#TOC-Dependencies-Android-Libraries-and-Multi-project-setup.