Weekly readings #2

This are my recommended readings for this week.


muppetspairprogrammingA good introduction to pair programming. Probably one of the more overlooked programming technics but with no doubt one of the most effective ways to guarantee quality code and improve the technical skills of a team.




Roman Nurik posted in the Android Developers Blog a good check list to port our existing Android apps to the new Material design style.



This is a nice one for the vintage code lovers and specially if you want to see how the C language code looked like 20 years ago. From the Computer History Museum in Mountain View you can download the source code of the Microsoft Word for Windows Version 1.1a.  Love it!

Screen Shot 2014-11-08 at 14.23.03

Microsoft Word Version 1.1



This one is a video from the Google Developers community on Google+ that remarks how important is to have our app indexed on Google search.


And finally a free book from Google entitled “The Secrets to App Success on Google Play”.



Weekly readings #1

This is the first of a series of posts just to share interesting things I’ve read during the week related to Software Development, not exclusively about mobile.

In this post on ADMag, David Ramel explains how a couple of studies found that mobile apps are failing to provide the user proper information about how and what personal data might be collected and how it would be used:



Peter Bright comment on this post a security hole discovered on WebKit, the open source engine used on the native Android browser. Basically it allows malicious websites to inject JavaScript code into other websites.



Really interesting report about the status of the Android platform, fragmentation, devices and version statistics and good tips for the Android developers.



A nice article about good practices and tips on Android testing.



And finally some advices about code reviews.


HTTP networking on Android using Volley

One of the most common functionalities that as Android developers we need to implement is the network communication. Almost all apps at some point needs to get some kind of data from a server, web service, etc.

We could implement our own classes using for example the Java HttpURLConnection, but as pragmatic, productive and lazy developers we should always try to don’t reinvent the wheel and find some reliable and well tested library.

Two of the best and more used options are Retrofit from the Square people and Volley from Google, which I’m going to focus in this post and I will leave Retrofit for another post.


What is Volley?

Volley is a library created by Google that offers out of the box a set of very cool features, amongst others :

  • Concurrent connections.
  • Automatic requests scheduling and cancelation.
  • Memory and disk response caching.

Here you can find a good talk at the 2013 Google I/O conference from Ficus Kirkpatrick:


Integration in our project

So, let’s see how to use it. First thing we have to clone the project from Git:

and then import it in our project or make a .jar and include it as a library.

Probably our app will be making requests in different activities quite often so the most optimum way to manage the life of our Volley object is implementing a Singleton class and create the instance it on the Application class instead or creating a new object on each activity. This singleton is going to contain the RequestQueue object that will manage the requests concurrency. Something like this:

    private static VolleyManager mInstance = null;
    private static Context mContext;
    private RequestQueue mRequestQueue;

    private VolleyManager(Context context) {
        mContext = context;
        mRequestQueue = getRequestQueue();

    public static synchronized VolleyManager getInstance(Context context) {
        if (mInstance == null) {
            mInstance = new VolleyManager(context);
        return mInstance;

    public RequestQueue getRequestQueue() {
        if (mRequestQueue == null) {
            // getApplicationContext() is key, it keeps you from leaking the
            // Activity or BroadcastReceiver if someone passes one in.
            mRequestQueue = Volley.newRequestQueue(mContext.getApplicationContext());
        return mRequestQueue;

    public <T> void addToRequestQueue(Request<T> req) {



Now we are going to implement a simple HTTP GET request that will retrieve a Json object. Volley offers four types of requests responses: “StringRequest”, “ImageRequest”, “JsonObjectRequest” and finally the ability to implement our custom request.

In this example we will be using a JsonObjectRequest. It’s based on real code from our public transport app BilbaoMoves, where we are calling to our server to get the real time arrivals of a specific transport stop. I just changed the endpoint url and the classes names.

It looks like this:

	JsonObjectRequest jsObjRequest =
        new JsonObjectRequest(Request.Method.GET, "http://urlToAnAwesomeEndpoint/webservice/",
                null, new Response.Listener<JSONObject>() {

            public void onResponse(JSONObject jsonObject) {

				Gson gson = new Gson();

                MyExampleClass myExample =
                    gson.fromJson(jsonObject.toString(), MyExampleClass.class);

				//	Do something awesome here with myExample object
				//	.......

        }, new Response.ErrorListener() {

            public void onErrorResponse(VolleyError error) {

            	//	The request failed  😦

        // Access the RequestQueue through the singleton class.



Creating a HTTP POST and send parameters in the request is quite straightforward as you can see in this example:

ExampleClass exampleObj = new ExampleClass();

JsonObjectRequest req = new JsonObjectRequest(URL, new JSONObject(exampleObj),
     new Response.Listener<JSONObject>() {
         public void onResponse(JSONObject response) {
             try {
                  //   Everything went OK
             } catch (JSONException e) {
     }, new Response.ErrorListener() {
         public void onErrorResponse(VolleyError error) {
              //   Hmmm... Something went wrong

// add the request object to the queue to be executed



Cancel a Request

Sometimes we will need to cancel a request, for example when the user close the app or change to a different activity where we don’t need any more the data provided by the request. We could place the cancel request code in the onStop event of our activity, something like this:

protected void onStop () {
    if (mRequestQueue != null) {


And that’s all. This is a basic introduction to how to make basic requests, but Volley offer another really interesting and useful features like caching and image loader (eg. to populate a list view with images asynchronously), but that will be material for another post. Until then, please all comments, suggestions and questions are very welcome!


Tagged , ,

Source Code Version Control for Android with Eclipse and EGit (II)

In the previous post we explained how to install and configure EGit and how to clone an existing project to our local repository. In this post, I’m going to explain how to add a new project to our local Git repository and then upload it to the remote repository in our Git server host.

Ok, first of all you have to import an existing Eclipse project or create a new one. Then right button on project and select Team/Share project.  In the next window select Git and then click on Create new repository or select an existing one and then click Finish.

You’ll see that the icons of the files has been decorated. Right click on the project and press Team/Add. With this we have added the files to the Git Index.

Now right click in the Bin folder of our project and press Team/Ignore. Doing this we avoid to commit the binary files of the project.

The next step is right click again on the project and Team/Commit, writing a nice comment.

Copy the URL of your remote repository, it’s something like this: “git@git.assembla.com:YOUR_PROJECT_NAME.git”, in this case our host provider is Assembla, but you can choose whatever you want.

Finally, right click and Team/Remote/Push. Eclipse fill up all the fields. Then just press Next, Next, and Finish.

And that’s it. If everything went well, you will have your project on your remote repository.

As usual, if you have any doubt, don’t hesitate to contact me.


Source Code Version Control for Android with Eclipse and EGit (I)

In this post I’m going to explain how to install and configure the EGit plugin for Eclipse and how to clone an existing project from a Git repository in a web based hosting service, in my case Assembla.

We assume that you already have a hosting service account and that you’ve uploaded your public key file and that there is a project to clone.

So let’s start step by step. First of all, open Eclipse and go to “Help/Install New Software…” and type “http://download.eclipse.org/releases/indigo/&#8221; in the text box to the right of “Work with:” text.

Press Add and then you will see a list of categories of installable software. Inside Collaboration category press Eclipse EGit and the Next, Next, and Finish.

After restart Eclipse, copy the git URI that you hosting service tells you for the project, it should look something like this: “git@git.assembla.com:PROJECTNAME.git”. In this case is “assembla” but it’s depends on your hosting name.

Now open up a new perspective of the “Git Repository Exploring” and press the button “Clone a Git repository”. It should already get the URI from your clipboard and fill everything out for you, so just press Next, Next, and Finish and…  Voila!  You have downloaded your project.

Now we have to import the downloaded project to our workspace in order to start to work with it. So just go to Eclipse “File/Import…”, now select “Git/Projects from Git” and press Next. You’ll see the downloaded folder, press Next and now choose “Import existing project” and select the project that you want to import then Next and Finish.

And that’s it!  If everything went well you have your project ready for compile and have fun!

To Commit, just right-click your project and select Team/Commit.

For pushing to your remote repository, go Team/Push and set it up when doing this the first time – Click next on the first screen, nothing to see here. On the next screen, choose “master [branch]” and “Add spec” next to it. Close it off with next and then finish.

And that’s all. I hope that you find it useful and if you have any doubt don’t hesitate to contact me.

Tagged , ,

Test Driven Development (TDD) with Google C++ Testing Framework and Visual Studio (III)

And first of all, why should I use Google Test Framework?  There are several reasons to choose Google Framework between other options and you can find out more about it on their website, but I’ll give you two of my reasons:

  • It’s designed to be portable. You can use it on Windows, Mac and Linux and I can use it on Visual Studio and Borland Builder C++. That’s cool.
  • Automatically detects your tests and you don’t have to set specifically wich tests must run.

Ok, let’s start downloading the framework from here.

Unzip the gtest file and put it in the Visual Studio Projects folder or in any other folder where you have your projects. You’ll see several folders, each one belongs to a different platform. In our case we’re going to use the Visual Studio’s framework, so go inside the “msvc” folder, open the gtest solution and compile and then follow the steps:

  1. Create a new console test project with Visual Studio and C++ language.
  2. Add to this solution the projects “\msvc\gtest” and “\msvc\gtest_main” of the “gtest” solution that we compiled before.
  3. Go to the project Properties and in the Configuration Properties > C/C++ > Code Generation set “Basic Runtime Checks” to “Both (/RTC1, equiv. to /RTCsu) (/RTC1)” and set “Runtime Library” to “Multi-threaded (/MT)”.
  4. In this Properties page, set the “Optimization” option to “Disabled”.
  5. Also in  Configuration Properties > C/C++ >General > Additional Include Directories add this line “$(InputDir)\gtest-1.3.0\include” for All Configurations (Relese/Debug).

Ok, now add a new .cpp to our Test Project, for example “TestBattery1.cpp” where we are going to write our first Test using an example that you can find in the Google Framework website, which defines three steps:

  1. Include necessary header files.
  2. Use the TEST macro to define your tests.
  3. Call RUN_ALL_TESTS() in main().

In this code example, we test the function Factorial. You can find the function here and the tests code in this link:

// Tests factorial of 0.
TEST(FactorialTest, Zero) {
EXPECT_EQ(1, Factorial(0));
// Tests factorial of positive numbers.
TEST(FactorialTest, Positive) {
EXPECT_EQ(1, Factorial(1));
EXPECT_EQ(2, Factorial(2));
EXPECT_EQ(6, Factorial(3));
EXPECT_EQ(40320, Factorial(8));

And that’s all for today.Finally, I leave here  a very good book about TDD but in this case with C#:


Test Driven Development (TDD) with Google C++ Testing Framework and Visual Studio (II)

Probably, like every developers, what you want is to start coding and see how is that of Google Testing Framework and how does it works. But not yet, my friend. Today we are going to have a look to the Unit Testing concept.

A “Unit Test” is a piece of code implemented to test a unit of work, which means that we are going to check the correct implementation of a requirement. For me the more important characteristics of a unit test are:

  • Repeatable and predictable.  It has to be designed to be executed  every time you needed and the result always must be consistent. Imagine that you’re testing an algorithm and you launch the test and it’s returns different results to the same parameters. Not good….
  • Isolated. You have to test only what is inside that function. Nothing else. That means that other modules, functionality or parts of your application shouldn’t be tested. For example, if you’re testing a function that reads a XML tag, don’t test in the same unit test a XML write routine.

Now, the process of executing unit testing is:

  1. Prepare the test performing some operation, initializing variables, etc…
  2. Launch the test.
  3. Check results
Ok, enough, it’s too much theory. We love coding and everything is much clear with examples, so in the next post we will start creating our first Unit Test with Google C++ Testing Framework!
Stay tuned!


Test Driven Development (TDD) with Google C++ Testing Framework and Visual Studio (I)

Test Driven Development has become one of the most important and known paradigms in software development.  We could say that is part of the Agile methodologies that are changing the traditional Waterfall way of work.  But, what exactly TDD is?

If we summarize in a few words, we could say that TDD is just write first the test, and then write the code. That’s it.  At the beginning it might seem a bit strange and you have to change the way you think when you are about to write a routine or a new class, but it has a lot of benefits that worth it:

  • Ensures quality from the start. If you have any bug, the test will fail at first attempt.
  • Maintains clean your modules of unused code.
  • Provides regression testing. If you change a piece of code, you can be sure that it will not affect to any other functionality.
  • Produces simpler and more focused APIs, classes and libraries. When you are developing a method that has to pass a specific test, you avoid the temptation of mess up your method with a different functionality.
  • It’s much easier to match the code and business requirements.

There are a lot of different frameworks to implement Unit Testing and start to practice with TDD. Here you can find a huge list.

In this series of post for C++ language, I’m going to focus on the Google C++ Testing Framework. It’s been developed by Google and I find it quite simple and useful.  In the next post we will explain how to use it and in subsequent posts I’ll try to explain other frameworks for .NET.

Stay tuned!