inaka

Latest blog entries

/
The Art of Writing a Blogpost

The Art of Writing a Blogpost

Apr 11 2017 : Matias Vera

/
SpellingCI: No more spelling mistakes in your markdown flies!

Feb 14 2017 : Felipe Ripoll

/
Fast reverse geocoding with offline-geocoder

Do you need a blazing fast reverse geocoder? Enter offline-geocoder!

Jan 18 2017 : Roberto Romero

/
Using Jayme to connect to the new MongooseIM REST services

MongooseIM has RESTful services!! Here I show how you can use them in an iOS application.

Dec 13 2016 : Sergio Abraham

/
20 Questions, or Maybe a Few More

20 Questions, or Maybe a Few More

Nov 16 2016 : Stephanie Goldner

/
The Power of Meeting People

Because conferences and meetups are not just about the technical stuff.

Nov 01 2016 : Pablo Villar

/
Finding the right partner for your app build

Sharing some light on how it is to partner with us.

Oct 27 2016 : Inaka

/
Just Play my Sound

How to easily play a sound in Android

Oct 25 2016 : Giaquinta Emiliano

/
Opening our Guidelines to the World

We're publishing our work guidelines for the world to see.

Oct 13 2016 : Brujo Benavides

/
Using NIFs: the easy way

Using niffy to simplify working with NIFs on Erlang

Oct 05 2016 : Hernan Rivas Acosta

/
Function Naming In Swift 3

How to write clear function signatures, yet expressive, while following Swift 3 API design guidelines.

Sep 16 2016 : Pablo Villar

/
Jenkins automated tests for Rails

How to automatically trigger rails tests with a Jenkins job

Sep 14 2016 : Demian Sciessere

/
Erlang REST Server Stack

A description of our usual stack for building REST servers in Erlang

Sep 06 2016 : Brujo Benavides

/
Replacing JSON when talking to Erlang

Using Erlang's External Term Format

Aug 17 2016 : Hernan Rivas Acosta

/
Gadget + Lewis = Android Lint CI

Integrating our Android linter with Github's pull requests

Aug 04 2016 : Fernando Ramirez and Euen Lopez

/
Passwordless login with phoenix

Introducing how to implement passwordless login with phoenix framework

Jul 27 2016 : Thiago Borges

/
Beam Olympics

Our newest game to test your Beam Skills

Jul 14 2016 : Brujo Benavides

/
Otec

Three Open Source Projects, one App

Jun 28 2016 : Andrés Gerace

/
CredoCI

Running credo checks for elixir code on your github pull requests

Jun 16 2016 : Alejandro Mataloni

/
Thoughts on rebar3

Thoughts on rebar3

Jun 08 2016 : Hernán Rivas Acosta

/
See all Inaka's blog posts >>

/
How to automatically generate different production and staging builds

Henrique Boregio wrote this on December 22, 2014 under android, gradle, inaka .

Today we're going to see how to create separate builds for a production and staging environment using the new build system used by Android: Gradle.

What is Gradle?

Gradle is the new build tool used by Android that comes bundled in Android Studio. You can find out more information about it in the official website (Gradle Website), but basically, it's a tool that manages dependencies, lets you specify custom tasks to run at different stages of the build process, automates deployment, etc.

What are flavors

One interesting feature of Gradle is the ability to define build variants, or product flavors. It's a much needed feature that tries to take the pain away from setting up very typical scenarios in developing Android apps, such as: * Building apps that have a free and premium version without separating them into different projects. * Building apps that share a common codebase but have different assets and package names. * Generating different builds according to our needs (E.g. a build pointing to a production server vs a staging server)

Production vs Staging builds

Let's imagine that we're building an app which talks to a backend server. We have 2 different instances of the backend server (production and staging), and want to be able to quickly point to one or the other. A simple approach is to define a production and staging endpoint variable in our code and just comment out the one we're interested in.

This works, but a few subtle problems might come up. First, it's easy to forget to change those variables, so we might end up accidentally mixing them. Second, using this approach, we'll always have 1 version of the app installed on the same device (Wouldn't it be nice to have a production build and a staging build living side by side?). And last but not least, you'll be forced to spend part of your day answering questions such as "Hey, is build X pointing to production or staging?" Who knows..?

Now that we know what the pain points are, what exactly do we want? To keep things simple, we want to be able to do 2 things: * Quickly switch from a production to a staging environment without having to modify our source code. * Given an APK, be able to visually see where this APK points to, also without modifying our source code (or put in another way, without visual easter egg indicators in the app UI itself).

We can very easily achieve this by doing the following: * Inside our project/app/src folder, create 2 folders. One named 'production' and another one named 'staging'. * Inside each one, replicate the values folder of the main project and place a strings.xml file with the following content:

project/app/src/production/res/values/strings.xml

<resources>
    <string name="root_url">http://production.service.com/api</string>
</resources>

project/app/src/staging/res/values/strings.xml

<resources>
    <string name="root_url">http://staging.service.com/api</string>
</resources>

Nothing fancy above. We simply define our 2 existing endpoints. Now, in you project/app/build.gradle file, add the following code inside the android { } section of the file:

productFlavors {

        production {
            applicationId "com.inaka.app.production"
        }

        staging {
            applicationId "com.inaka.app.staging"
        }

}

What are we doing here? We're simply saying that we want 2 flavors of our app with these package names. By setting different package names, we'll be able to have 2 different APKs installed side by side on the same device.

But how do we know which one is a production build and which is the staging one? A neat trick is for each build to have their own custom launcher icons. For example, we could set the launcher icon for the staging build to have the text "staging" displayed over it. How do we do this? All we need to do is create a res folder inside the staging and production folders and inside this res folder, create the common drawable folders (drawable-hdpi, drawable-xhdpi, etc) and place the launch icons inside them.

As you might have noticed by now, each flavor needs to respect the exact folder structure as established by our main source code. And whenever we switch from one flavor to another, Gradle basically replaces our main resources with the ones we've defined in our flavor. Which gets us to the final stage of this process. How to we actually tell (in our case Android Studio) which build to create. You'll notice that Android Studio has a tab called "Build Variants". If you click on it, you'll see a list with the flavors we've defined. Select the one you want, and you're set!

Conclusion

As you can see, it's pretty simple to create custom flavors and automate certain tasks that we'd otherwise have to do manually. Even though we've only seen a simple example, this same approach can be used to create more sophisticated build flavors, with not only different resources, but also custom source code associated with each flavor.