Implementation vs api in Android Gradle

Today we will learn about Implementation vs api in Android Gradle. While working on Android Gradle files you must have come across these keywords multiple times. The ‘api’ keyword is mostly used when you are working on modular applications and working on a library module.

Definitions

‘implementation’: This configuration is used to declare dependencies that are internal to your module. These dependencies are required to compile your module’s source code but are not exposed to other modules that depend on your module. The dependency is available to other modules only at runtime.

‘api’: This configuration is used to declare dependencies that are part of your module’s API surface. These dependencies are required for compilation and are exposed to other modules that depend on your module. So that it’s available to them at both runtime and compile time.

Comparison between the two

implementation	api
Used for dependencies internal to your module.	Used for dependencies exposed in your module's API.
Dependencies declared are not visible to other modules.	Dependencies declared are visible to other modules.
Use to minimize coupling and hide implementation details.	Use to expose dependencies in your module's API.
Available to other modules at runtime.	Available to other modules at runtime and compile time.

VIDEO TUTORIAL

Example

We will see the usages in one of my previous article where we learnt to create an Android Library. Where we created networkmodule which contains Retrofit instance to print the base url.

By default the dependency is included as ‘implementation‘ as shown below:

If we will try to access the Retrofit into our main module then we will be getting error as shown in below image:

To overcome the error we will change the ‘implementation‘ to ‘api‘ as below:

Here, the Retrofit library is being added to the module as part of the public API. Any module that uses this library will be able to see the Retrofit classes and methods.

 

Using the api will allow main app module to access the Retrofit classes and methods.

 

As ‘implementation’ is the default for including dependencies in the project. If you are using ‘api’ then read the pros and cons before using it.

Pros of Using ‘api’

1. Modularization: It allows you to modularize your project effectively. Exposing dependencies through ‘api’ facilitates communication between modules and promotes a modular architecture.

2. Consistent APIs: It ensures that all modules use the same version of the dependency. This helps maintain consistency across the project and reduces the risk of compatibility issues caused by using different versions of the same library in different modules.

3. Reusability: It allows other modules to reuse the functionality provided by those dependencies. This promotes code reuse and avoids duplication of code across different modules.

4. Dependency Management Simplified: It simplifies dependency management by clearly defining which dependencies are part of your module’s API. This makes it easier for developers to understand and manage your module’s dependencies.

Cons of Using ‘api’

1. Increased Coupling: Using ‘api’ you expose the dependencies to other modules, which increases the coupling between modules. This can make it harder to refactor or change dependencies in the future without affecting other modules.

2. Build Time Overhead: It increases build times, especially in larger projects. When a dependency changes, all modules that depend on it may need to be recompiled, leading to longer build times.

3. Abstraction Leakage: It can lead to abstraction leakage, where implementation details of the dependency leak into other modules. This can make it harder to maintain and understand the codebase.

4. Reduced Flexibility: It reduces the flexibility to change the internal implementation of your module without affecting other modules. This can limit your ability to optimize or refactor your code.

Choosing between ‘implementation’ and ‘api’

• If you’re building an internal module and you want to keep dependencies encapsulated within that module, use implementation.
• If you’re building a library or a module that is meant to be consumed by other modules and you want to expose dependencies to those consuming modules, use api.

You can use a combination of implementation and api within the same project to achieve the desired level of visibility and encapsulation for each dependency.

 

Initially, you can start with implementation and later switch to api if you find the need to expose the dependency’s API to other modules. Regularly review and adjust your dependency configurations based on your project’s evolving requirements.

By understanding the nuances between ‘implementation’ vs ‘api’ in Android Gradle, you can better manage your project’s dependencies and ensure a well-structured, maintainable codebase.

Thanks