I have a little open source project that I am trying to slowly improve. One of the steps I’m taking to do this is to add some tests and code static analysis. If something is running correctly I don’t want regressions so I need to plug it to CI so it runs for every commit. A lot of people are using Travis so I decided to give it a try. The first steps can be found at Travis’ getting started page.

My project is a PHP project but it needs node to run grunt tasks so I was worried about not being able to specify two programming languages in the yml file. Luckily Travis includes a version of node on all VMs no matter what type of project you are using, so I could freely use npm and grunt:

1
2
3
4
5
language: php
php:
  - "5.4"
before_script: "npm install"
script: "./node_modules/grunt-cli/bin/grunt"

I also found that if you have a very specific requirement you can even use apt-get to download dependencies and then you will be able to use it as part of your task.

I have been slowly working more with Android and as I go I find myself in the need to do more complex stuff. I have been recently working on the UI side and I have been asking friends who have more experience with Android to review my code and I learned that I was doing some things the wrong way.

I come from a web development background so while I was learning how to use Android layouts I was looking at ways to translate what you do in Android with what you would do in the web. In Android we have layout files which are written in XML and live in res/layout/. When I started I pictured these being my HTML files, which is not completely correct. For styling android apps we use another XML file that lives in res/values/, these I thought of as being my CSS files.

The more I have been working on large scale projects the more I have seen the use of REST (Representational State Transfer) for almost everything. The basic concept of having an HTTP end point where you can make a request and get a JSON as a response is pretty easy to understand, but since I have never build a service from scratch I wanted to dig a little deeper into the architecture and requirements of this type of services.

Representational State Transfer

REST makes us think of our services as an interface to let the client know the current state of a resource. The state of our resource is saved somewhere in the server (Maybe in a database) and is modified or retrieved via HTTP verbs. For example, lets say we have a people table in a database and we want to know the current state of a specific person, we would do a GET request to this url:

1
http://service.url/people/1234

And we would get a response with the information that is currently stored in the database about the user with an id of 1234.

I have written about unit testing in other posts so this time I will only focus on how to create a test suite and test cases for Android applications. Writing unit tests for Java is a little different than doing it for other languages like JavaScript because Java is not only a strongly typed language, but also is a lot less dynamic than JavaScript.

Creating a test suite

Good developers create tests for all their projects, and for Android there is an standard place where those tests live. Although you don’t really have to do this, it is recommended that you create a tests/ folder in the root of the Android project under test, at the same level as the src/ folder:

1
2
3
4
5
6
7
8
MyProject/
    AndroidManifest.xml
    src/
    ...
    tests/
        AndroidManifest.xml
        src/
        ...

Android provides a few ways to persist information between sessions, with the simplest option being the preferences system. The preferences system allows you to save key value pairs with primitive data types as values.

To use preferences you need to import SharedPeferences and then use getSharedPreferences() within your activity to get the preferences object:

1
2
3
4
import android.content.SharedPreferences;

// Somewhere in your code
SharedPreferences settings = getSharedPreferences("SomeKey", MODE_PRIVATE);

Recently I have been mostly working in JavaScript and per my project standards, all my tabs are replaced by 2 spaces. The problem with this is that for other projects in other programming languages the standard tab width is 4 spaces, so it becomes annoying to have to hit tab twice to indent a line correctly. To fix this you can declare settings specific for a language if you place them on ~/.vim/ftplugin/LANGUAGE.vim.

Since currently I am working on an Android app and I want a tab width of 4, I created the file ~/.vim/ftplugin/java.vim and added this content:

1
2
3
" Make tabs 4 spaces wide "
set tabstop=4
set shiftwidth=4

When I switched to git for the first time I had a very hard time understanding what rebasing did to a point where I totally avoided it. I had been doing all my work on private and public repositories by going to master and merging to my feature branch or to a team member’s branch. I was happy with this way of working until I started on my new job a few months ago and they had a rebase based workflow. It goes something like this:

1
2
3
4
5
6
cd repo
git pull --rebase
// Do some work and add stage it
git commit -m 'Some message'
git pull --rebase
git push origin master

In this little example I am working in my local master branch, but if I wanted I could create a feature branch and rebase it to master as needed. The most obvious benefit about this workflow is a very clean history. Lets look at a simple example of a merge based history:

If you just installed git in your computer you probably got a message telling you that your name and e-mail haven’t been configured and suggesting you to change them the first time you commit:

1
2
3
git config --global user.name "First Last"
git config --global user.email email@domain.com
git commit --amend --reset-author

This will set “First Last” and email@domain.com as your default name and email for any git repository you work on in that computer. This may be something you don’t want because probably you want to have different identities in different computers. One thing you can do is amend your commits with an alternate identity you want to use:

1
git commit --amend --author="First Last <email@domain.com>"

If you will constantly be working on this repository this will become annoying really fast, so instead you can set your identity for a specific repository by adding this to your .git/config file:

1
2
3
[user]
  name = First Last
  email = email@domain.com

I have been playing with 2D graphics in Android and it was a little hard to understand how to do some things that I needed. The API documentation for some functions doesn’t really do much of explaining you exactly what each argument does and how you can use them. After a little research I was able to draw everything I needed so I am going to try to summarize what I learned.

Paint

Most of the drawing functions on Android will take a Paint object as an argument. To use it you just need to instantiate the Paint class:

1
Paint p = new Paint();

You can specify one of three drawing styles: FILL, FILL_AND_STROKE, STROKE. In a very simple scenario you might want to fill a shape using a blue color, and you could do it like this:

1
2
3
Paint p = new Paint();
p.setStyle(Paint.Style.FILL);
p.setColor(Color.BLUE);

I am building a simple app that will need to graph some data, so I found myself in the need of using Android’s drawing library. There are a few good tutorials out there of how to do this using a canvas, but I read somewhere that it was possible to draw directly into a view and I wanted to try that. Drawing directly into the view is useful when you have data that you don’t need to redraw very often. When you use a canvas you have to manually call the onDraw method every time you want to show something, which makes sense for animations. For more static data you can draw directly into the view and the onDraw method will be called automatically every time the view it is shown to the user.