Ideas about Android engineering

I need a place to put some ideas about developing Android apps in a clean way.

As we want to test our domain in a quick and simple way, we need to write code testable with just the JUnit framework. We need to avoid using Roboelectric, PowerMock and that kind of frameworks, as they are not simpler than just avoiding them :·)

How to do that? Just try to avoid depending on Android things, like the Context, SharedPreferences, SQLite classes…

… and that’s all! Just a small post launched to the world!

Let’s talk about commit messages

… or look at this great Chris Beams post:

Everything started ’cause I requested a colleage about stop ending the messages with a period. And then, I realised that my messages starting with “adding”, “fixing” and other continous pasts doesn’t has any sense. So, I started writing in imperative.

Thanks Chris :·)

Why I don’t like rebasing

Hi @channel!

Last weeks I worked with the Vibbo‘s Android team. Changing from one team to another one is great to learn new things. You know everything about moving outside of the comfort zone so I will not talk about it… :·)

This article tries to list all the times that git rebase broke my heart. I know that there’s a hot conversation about merging from develop to your branch or rebasing on develop. I always merged to fix conflicts, and some members of the Vibbo crew asked me to rebase over merge, so I went forward with rebasing. In addition, I tried to spread the word to another team… and well, I regret it.

The broken heart facts:

– When you rebase on another branch, you are requested to resolve every conflict it happened, commit by commit. So, if the branches are not too small, you will be asked several times. If you resolve conflicts on ten different files, it’s ok. But, if you have to resolve conflicts ten times in the same file… madness.

– If you missed a conflict and you screwed the whole code (’cause you are not perfect, my friend), you don’t have a “merge commit” where you can find your mistake. You have rebased. No merge commit. Good luck!

– Push force will be your new friend but HEY. git push origin –force pushes your branch to origin, right? Well, yes, but only partially. In Windows (at least, the version I had) it pushes ALL your branches. So, if you had an old version of develop, you will push it and screw all your friends. There’s a –force-with-lease version in the latest versions of git but hey, it’s not the standard –force.

– The Pull Request conversation gets disordered. A common Pull Request seems a Twitter timeline. Two commits, one comment, one commit, three comments. Then, you push force your just rebased branch, and all the messages are moved to the start of the conversation and all the comments after them. Goodbye, timeline!

Conclusion: if you are alone in a project, or you work with very committed colleagues that love to life at risk and you look at the commits history every night to see its shape and colour, rebase could be a good option for you. But if you are in a real world, you are an average git user or you work with average git users… don’t rebase.

Your first production-ready Jenkins

You heard about Jenkins and you want to try it. Good news: it’s so simple to do it in a production environment. So, skip trying it at your localhost and then installing it again in your production environment. The steps are these:

1. Get a production server. We use to get it at To build Android apps you’ll need 2GB of memory. About the number of cores: it will work with only one core, but if you can afford a machine with more cores, gradle will use them. Fewlaps’ Jenkins has two cores and it performs great.

2. Install Java 8. You can also use Java 7 but… well. At some time, someone, will write a lambda, and you will need to update to Java 8 :·)

su root
echo "deb trusty main" > /etc/apt/sources.list.d/webupd8team-java.list
echo "deb-src trusty main" >> /etc/apt/sources.list.d/webupd8team-java.list
apt-key adv --keyserver --recv-keys EEA14886
apt-get update
apt-get install oracle-java8-installer
java -version

3. Install Jenkins

4. http://yourserver:8080 it works! (note that it’s not too fast starting the daemon)

5. Install git, mercurial… All the things that Jenkins will need to pull your projects from your repos. You know:

apt-get install git
apt-get install mercurial

… and so on


Important: before creating any Job, check your security configuration. Create an user for you, another one for every colleague, and grant them the needed permissions. Also check that “anonymous” doesn’t have any permission, and that the “users can register to the environment” box is not checked.

There’s an issue builiding Android things, related to the AAPT. Fix it with this solution:

Wep! More info! Your Android SDK will be downloaded at /var/lib/jenkins/tools/android-sdk/

Wep! More info! If you have issues starting an emulator, apt-get install libglu1-mesa

Xerrada sobre testing, CI i CD a Android


Aquest dimecres 17 de febrer he fet una xerrada introductòria de testing, CI i CD sobre Android als Betabeers. Ha estat al Mobile World Centre, al C/ Fontanella 2 de Barcelona. És a dir: a la cosa aquella de Telefònica al costat de Plaça Catalunya.


Vet aquí el video de la xerrada:

El briefing era aquest:
Hola! Soy Roc Boronat, desarrollador Android en Fewlaps. Hace un año y medio creía que testing y CI eran cosas de pijos, así que este último año he escuchado mucho para aprender por qué los grandes lo promueven. En esta charla compartiré mi experiencia sobre testing en Android, TDD, y CI, aplicado a varios proyectos reales. Y todo, desde el punto de vista del que no se lo creía demasiado.

Espero que us sembli interessant! I per suposat, qualsevol feedback és benvingut!