Cook Up Your Build Variants!
If you have a staging and production environment on your server side and you are now developing a mobile app, you will find this post very useful!
During development, you may encounter some challenges:
- How to make the mobile app work with both environments.
- How to switch between them with ease and increase productivity.
- And, most important, how to keep the code clean and without this logic wired into it.
Gradle and Android Studio are a powerful combination that provide product variants as a way to overcome these barriers.
Bring it on with Build Types!
Build types specify ways to build and package your app. By default, two build types are created: debug and release.
The main difference is that the first one turns the debuggable flag on, and lets you debug your application, whereas the second one comes with proGuard enabled. ProGuard obfuscates the code of your app to make reverse engineering a hard task for curious people.
You can leave this configuration as the default one. Also, note that some libraries might have problems with ProGuard, or specific instructions to make them work with it.
Essential ingredients: Signing configurations
You will probably use at least two different keys to sign your application: one for development and another one for the PlayStore version.
You can choose to include the sensitive information directly in the main gradle file (which means it will also be in your repository) or extract it into a separate file that will not get into your repository. We will name it keystore.gradle:
You then need to get the variables into your gradle build script. To do this, you simply have to apply the file at the beginning of your gradle script:
Product Flavors: The Icing on the Cake
Flavors are useful to make different versions of your app. They all can differ in assets, resources, configuration or code. We will use them to make a version of the app that is used for development, hitting the staging API endpoint, and another final version, that calls the production API.
First we link each flavor to a signing configuration. This is useful when you employ third party services that use a keyhash to identify the app, such as Facebook. It will also prevent you from accidentally uploading a staging version of the app to Google Play, since the key used to sign the app must always be the same (the production one).
Then we have to change the applicationId on the stage flavor, concatenating the default one with an identificator “stage”. You should do this because it will allow you to have both the production and staging version installed on your devices, something useful when developing.
You should do the same with the versionName, since some services display information based on the version name (Analytics, for example).
How to tell both app flavors apart when installed on your device? You can make a different launcher icon. For example, a grayscale version, or include a watermark on it.
To achieve this, you have to recreate the res folder structure in another folder named after the product flavor (in this case, “stage”). Then you’ll have to save the new launcher icon there:
In order to make the stage flavor hit the staging API endpoint, we could make a BaseConfiguration class inside the stage and production folders with the different configurations.
Now extend that class with a Configuration class in the main folder that contains the common configuration which won’t change between flavors.
In the remaining app code, we can call the Configuration class directly, as it will inherit the configuration from the flavor class.The final folder’s structure will look like this:
Freshly Baked Product Variants!
Now that everything is ready, we can easily change between the different product variants from Android Studio UI. Each variant is made by combining a build type and a flavor.
In this case, this will give you four different combinations. You will probably find only three of them useful:
- productionRelease: A release version that can be uploaded to Google Play Store. This version should be tested by QA.
- productionDebug: It’s used to debug a version of the production app that might have been uploaded to the Google Play Store. It’s also useful to debug errors with third party services that require the app to be signed with the production key.
- stageDebug: The main variant used for development. It will call the staging API and will be prepared to debug.
Now you are ready to keep developing amazing apps without worrying about changing the code to test your app against your staging and production servers!
Posted by Federico Ramundo(federico.ramundo@wolox.com.ar)
