4

Building a multi module Android app using Gradle plugin 3, instead of declaring a dependency with compile one should use implementation or api. The latter basically works like compile. Using implementation, the dependency is hidden from any module depending on this module.

So, let's say I have three modules A, B and C. B depends on A and C depends on B and A, like this: A <- B <- C (Gradle plugin 2 compile). With Gradle plugin 3 I could do just the same using "api". Would it make any difference if I explicitly declared all dependencies using implementation, like A <- B, A <- C, B <- C?

Asking a bit different: Why would I use api at all instead of explicitly declaring dependencies using implementation? It seems "saver" to avoid api. Is api just for convenience or am I missing any side effects?

Oderik
  • 2,242
  • 2
  • 16
  • 25

2 Answers2

1

It's about transitive dependencies. Read more here: https://medium.com/mindorks/implementation-vs-api-in-gradle-3-0-494c817a6fa

Andrew
  • 1,383
  • 7
  • 21
  • Thanks, but that's what I already knew. Looks like I need to clarify my question. – Oderik Mar 02 '18 at 09:03
  • 1) 'implementation' dependency will speed-up building of multi-module app (when you have 20-30 modules building process may waste a lot of time) 2) 'implementation' will save you from using unclear dependencies. Let's see an example. You added some library which depends on rxjava1. And you will find that you may use rxjava1 at your code, but some day they will migrate to rxjava2 and your build will fail (but library api is same and you didn't change anything at your code) so this behavior is very inclear. – Andrew Mar 02 '18 at 09:57
  • Does that apply to the scenario I described above? Again, why would I use api at all? – Oderik Mar 02 '18 at 10:01
  • So I suggest to use implementation, not api. Api may be useful when you have a few huge, hard-to-setup modules and a thin module that just performs huge modules initialization. I don't other usecase to use api – Andrew Mar 02 '18 at 10:06
  • 1
    Hmm, api may be used for dependencies which is needed for the public API of your module. – Andrew Mar 02 '18 at 10:11
  • I just had the same idea when getting a coffee. ;) If you create an answer of it (mentioning something like "yes, if you don't create any public api"), I'm going to accept it. – Oderik Mar 02 '18 at 10:15
1

In general, implementation recommended to use (it will speed-up project building and protect from dependency leaks)

But if your module uses some it's dependencies at it's public API those dependencies should be added with api configuration otherwise users of your module should add those dependencies manually.

Andrew
  • 1,383
  • 7
  • 21
  • 1
    One more scenario in favour of api: I included android.arch.lifecycle:extensions using implementation in a library module. The depending app module complained about a version conflict maybe due to an implicit dependency. I don't fully understand why, but using api instead of implementation for android.arch.lifecycle:extensions just did the trick. – Oderik Mar 02 '18 at 10:44