When looking at the BuildConfig
class generated by Android Studio and the Gradle plugin one can see that the BuildConfig.DEBUG
field is initialized using the Boolean.parseBoolean(String)
call instead of using one of the boolean literals true
or false
.
When I add custom build properties using Gradle I would simply do it like this:
android {
buildTypes.debug.buildConfigField 'boolean', 'SOME_SETTING', 'true'
}
But looking at the generated BuildConfig
tells me that Google has taken a different approach with the DEBUG
flag:
public final class BuildConfig {
public static final boolean DEBUG = Boolean.parseBoolean("true");
// more fields here
// Fields from build type: debug
public static final boolean SOME_SETTING = true;
}
What is the benefit of using Boolean.parseBoolean(String)
instead of literals?
There's a class called BuildConfig. java which is automatically generated by the build system. This class is updated automatically by Android's build system (like the R class). It already contains a static final boolean called DEBUG, which is normally set to true.
In recent versions of the Android Developer Tools (ADT) for Eclipse, there's a class called BuildConfig which is automatically generated by the build. This class is updated automatically by Android's build system (like the R class), and it contains a static final boolean called DEBUG, which is normally set to true.
Boolean literals inside the BuildConfig
class are going to produce IDE warnings when using them in your code (at least within Android Studio). For example when using it in a boolean expression Android Studio will (mistakenly) recommend to simplify the boolean expression because the constant value is always the same (for current build variant that is).
This warning is only because Android Studio does not know that the final value inside BuildConfig.SOME_SETTING
may be different for other build variants.
To keep the code clean and free of warnings you can tell Android Studio to ignore this specific warning by adding an IDE comment like this:
But again this will add some noise to the code and reduce readability. By using the Boolean.parseBoolean(String)
method to initialize your constant field, you actually trick Android Studio which will no longer be able to completely analyze your boolean expressions, thus not generating warnings any longer.
This approach is very useful, as it keeps your code clean and readable, without turning off important code analysis and generation of warnings.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With