CODEWITHSUNDEEP
javaandroidgradledependenciesdependency-management
Markus
Markus

Reputation: 2564

(Android) Runtime dependency managment with different flavors

I have an Android application.

I want to define a flavor of my application. This flavor will not include (for legal reasons) some of the dependencies in my main flavor. Not only can Gradle do this, but it seems like it was (more or less) the main reason Google adopted Gradle for Android in the first place

However, what I do not understand is how I deal with these missing dependencies at runtime. How will this affect all the places I have:

import package.which.is.only.available.sometimes.

and How do I test for the existence of the package when I try to call it's methods? I guess I could just use it and catch any CallNotFundExceptions, but that seems like a major hack.

Any input will be appreciated :)

Upvotes: 0

Views: 260

Answers (1)

CommonsWare
CommonsWare

Reputation: 1006674

This flavor will not include (for legal reasons) some of the dependencies in my main flavor.

I am not aware that you can readily exclude dependencies by flavor. You can add dependencies by flavor, using flavornameCompile (where flavorname is your flavor name).

How will this affect all the places I have: import package.which.is.only.available.sometimes

If that is in your main sourceset, your code will fail to compile, as the classes will not exist.

How do I test for the existence of the package when I try to call it's methods? I guess I could just use it and catch any CallNotFundExceptions, but that seems like a major hack.

Move the code into a separate flavor. Your main sourceset would contain code that is truly in common with both distribution scenarios, with no references to the conditional dependencies. One flavor would contain the dependencies and the code to use them; the other flavor would not.

For example, suppose that your two distribution scenarios are the Play Store and a direct download from your Web site, and the conditional dependency is the in-app purchasing (IAP) stuff from the Play Services Framework. You would have a google flavor with the dependencies (googleCompile) and its sourceset would use the IAP API. You would have a separate standard flavor that would do something else (e.g., use PayPal). The main sourceset, whenever it needs to do something related to in-app purchases, delegates to a InAppPurchaseStrategy class. There would be two separate implementations of that class, one in each flavor (and none in main itself), tuned to use the payment stuff appropriate for that flavor.

Upvotes: 2

Related Questions