Arrival in Spain, rather warm bus journey on Aerobus (pronounced - aye-row-booz). Then a very busy introduction to Barcelona followed when arriving at Plasa de Catalunya. There were a great many people there. Many with luggage. When walking to the apartment, although not far away, I was very glad to have a backpack hold-all rather than wheely luggage. The temperature difference was quite stark in comparison to back at home and the plane journey. So it wasn’t long before I was trying to find a place to put my hoodie, feeling especially like a backpacker with my hand luggage on my front like a baby.

The building itself was a sharp introduction to Spanish layout, the central elevator was very similar to that of the one we had while in Rome - though significantly more sturdy. There is a ‘Principle’ floor before the first floor, which was where we were met by the person who had buzzed us in from the street. It was soon clear that his English was very limited and he had in fact been expecting to buzz in someone else. So after a brief and beffudling exchange we established that we needed to go further up. We were still a bit unsure as to whether or not that was the host, despite looking nothing like their picture.

After some serious deliberation about which doorbell to ring - there appeared to be two close together, and one further away, all looking like light switches, so one was picked and we rang it. The Airbnb hosts were very friendly in greeting us, but with some surprise as they hadn’t actually let us in the building. They gave us a quick run through of the rooms. The place was much larger than it looked in the pictures online. The kitchen was just as lime green. There was going to be plenty of space to rattle around in for a week!

After briefly unpacking our things we went to the local mini supermarket (Supermercat, from this point on always referenced as ‘Super meercat’ by myself!). We made sure to stock up on plenty of beer and Gin for the next couple of days. Chris was confidently saying that he had looked up that the Markets would be open on Sunday, however later on he was slightly ridiculed for this and was branded with having the reputation for saying the opposite of the truth.

We didn’t really fancy cooking at all, so we had a skim of the plethora of food offerings that Barcelona had to offer on Google Trips, I settled on a Tapas bar called BETLEM - Miscelánea Gastronómica. We shared a bottle of wine and tried the Pork Dewlap, which is now the stuff of legend.

After all of the travelling we all got an early night - grateful in our decision to buy some bottled water, the tap water had a very pungent scent of chlorine, although we looked up online - after a lengthy task of typing in a huge password to use the WiFi - that it was quite safe to drink. Being techy, Alex and myself were pleased to see that the download speed was ample for us.

There are a lot of useful articles out there for improving your quality of life while developing on Android. I thought I’d collate some of my favourites so that I can help improve your experience, as well as provide a place for me to find more easily anytime I need to set it up again and don’t have my settings backup to hand.

First of all is IDE setup itself. Configuring Android Studio lists some nice quality of life improvements to help speed up and automate some areas of your every day development flow. I’ve even coloured my Logcat output to match. I find it makes those crash logs a little nicer on the eye, and that always helps.

Build time improvements

At the sacrifice of linting you can improve your build times by setting it to the latest version of android you’re supporting, each have their own type of improvements. I’ve not used this much yet, but I found the idea quite cool. Edit: This is actually for Multidex builds

Within your android hash:

productFlavors {
    dev {
        minSdkVersion 23
    }
    prod {
        // The actual minSdkVersion for the application.
        minSdkVersion 17
    }
}

Keep your Gradle wrapper up to date if possible. At the time of writing this means updating your gradle-wrapper.properties to have: distributionUrl=https\://services.gradle.org/distributions/gradle-2.10-all.zip

As soon as it’s okay for you to use I highly recommend trying out instant run in Android Studio. Essentially similar to JRebel but free.

Testing improvements

You can direct the outputs of your unit tests for quick access. To do this within your android hash add:

testOptions.unitTests.all {
    testLogging {
        events 'passed', 'skipped', 'failed', 'standardOut', 'standardError'
        outputs.upToDateWhen { false }
        showStandardStreams = true
    }
}

Handy libraries

Here are a few of my favourite libraries for time saving.

• Android Annotations - I’ve used a decent amount of and there’s a lot to say for the improvement in removal of boilerplate code, handy helpers and overall cleaner looking code.

• Butter Knife - The current hotness for view and resource injection. Much lighter weight than Android annotations if you’re not leveraging them much.

• Icepick - Compliments Butterknife by adding instance state annotations.

• RoboGuice - Another Dependency injector, lighter weight than Android Annotations

• Leak Canary - Helps you nail down your memory leaks

• Stetho - Lets you use Chrome to help view and alter SQL databases and Preferences in your app

• Square - A lot of well written and well maintained libraries

• OrmLite - Quick and easy databases

• MPAndroidChart - Fantastic looking charts and graphs.

• Codepath - Has a very long list of other libraries.

Video

A decent amount of tips for Android Studio are available in the Android Studio for Experts (Android Dev Summit 2015) video

At work we’ve supported a number of projects right through from IntelliJ and Maven to Android Studio with Gradle by hand. Android Studio now supports a better means of importing, upgrading and migrating a project to Gradle than before, but I’ve not been able to make use of this with our projects as they’ve evolved over time.

One of the recent changes to Android Studio has been better integration with tests. However for me this came at a cost. It depends a lot on the file structure of your application, so code blocks such as this can prove a bit more troublesome to manage:

(Gist deleted)

It’s easy to forget to update this regularly, particularly when adding a new build variant or build configuration. It also doesn’t help internally when switching between projects to help navigate to where a particular resource is located and update it.

To get ready to start using the built in test suite took a bit of work, but worthwhile for maintenance of this app. Moving the src folder to app/src/main/java was simple enough, but creating a working root level (Project) build.gradle took a bit more effort.

Choosing a suite

Next came a bit of experimentation with test suites. After dabbling with a bit of Roboelectric in the past I was keen to try that out again, but found that Espresso had been making an impact in the community with newer support. A key difference for me was being able to run on a real device, rather than a shadow copy of Android APIs, along with support for Marshmallow in the future.

Android Annotations

For a while now a key part of our toolkit has been Android Annotations. The setup guide for this details apt.arguments.androidManifestFile: variant.outputs[0].processResources.manifestFile

This caused a slight headache when attempting to run the tests, but it turns out the fix is rather simple by making use of the groovy ‘?’ operator making it read this instead: variant.outputs[0]?.processResources?.manifestFile

Once this was done a key thing is to make sure you’ve selected the correct build variant in the bottom left and test artifact, both are pretty self-explanatory. To get you kick-started with setup I also sorted out my DevStat app with it, which makes use of Android Annotations too. The tests are sparse, I want to use it as a bit of a test-bed with RecyclerView shortly. The one downside is I’ve had to bump the minimum SDK from 7 to 8, but as that’s now sub 1% distribution now I don’t see that as too much of an issue.

Next Steps

I noticed tests failed to run correctly unless the build variant was set to <flavor>Debug. While this is fine for me it’d be good to find out the reason behind it as some variants further down the line will likely have different logic or UIs.

Edit 17/01/2015: Android Studio 2 looks to be removing this