• Android Developer Quality of Life Tips

    Jan 20, 2016

    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.


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

  • Testing With Android Annotations

    Nov 24, 2015

    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:

    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

  • Bringing magic to Android wear

    Sep 12, 2014

    I've found a spot of time to try out the Android Wear SDK within the confines of the Android Wear Emulator. Hot out of Google, Android Wear offers the users the ability to view Google Now Cards, and interact with applications using a screen on their wrist. The interaction with the device seems to be primarily hardware buttons, touch, and voice - much like Google Glass. Sadly the emulator doesn't currently support interaction via voice.


    The currently available Android wear devices vary quite a lot already in terms of hardware features, size and shape. A personal favourite of mine is the Moto 360 by Motorola. It has a crisp design with smooth edges, which fits well with the expectation of how a watch looks. It'll be interesting watching what competition drives out with innovation.

      A key area for me personally is focusing on the battery life. At a bare minimum I'd want a Smart Watch to last for 24 hours, ideally a full week, between charges. A watch is something I used to wear without taking it off, including in the shower. It was something I'd have on and forget about. Nowadays I use my phone to check the time. But there are times - like when it's raining and I'm out walking in it - that I'd like to be able to check the time by glancing at my wrist, without battling with pockets getting all the more wet.


    It's quick and easy to get started with the Android Wear SDK. It's a simple download of the SDK as per other android releases. This'll be familiar to those who've used Android Studio and Eclipse. The IDE of choice for Android development here at Conjure is Android Studio. It's been pleasant to watch as it has evolved so far, and we look forward to seeing it shed the beta label and advance into version 1.0.

    The Android Studio project template quickly guides you through creating your first Android Wear application. Providing you with the most basic hello world to get you started. I didn't want to go too heavily into interactions between the phone and the Wear device using the emulator without a real Wear device at hand. So I thought I'd see just how similar it is to the Android SDK I've grown used to.

    I decided to expand on the "Hello World" a little more while exploring animations and seeing how they can be nice on a smaller screen too. So first and foremost I changed the background colour and changed some text. Straight away I noticed the differences between the square and round layout files. Having to repeat sections of views from Tablet and Phones to make a better experience this wasn't new territory for me. But the shape itself was. I noticed that the strings resources had both round and square versions. This was a handy thing that I generally would not have thought to do this. Generally copy remains the same on both phone and tablet even if the view is adjusted. The usefulness of this is particular tied to the different screen shapes. For example on a square watch you'd have access to the same screen width at whatever Y-coordinate. But on a round device, that could be at the top or bottom and result in your text being cut off. Ill-looking for the user. I decided I wanted to render 'Bringing the magic' along the bottom, that would bounce up from the bottom of the screen. I didn't want to just write a shorter button for the round layout file so I just bought up the height until it fitted. Working with the Android layout renderer was useful to spot and adjust this quickly.

    After I'd finished with fading in our Conjure logo and making the text bounce up from the bottom I thought it'd be nice to have a more continuous animation as a part of the background to make the app seem more alive and a feature-piece. So I picked an image that was originally designed for use on a Nexus 7. Coming in at a fair 1920 x 1920. Far too big to fit on a 320(dp) square display without scaling. Though to my surprise on the emulator it rendered fine on a virtual device with 512MB RAM and a VM Heap of size 32MB. Rendering large Bitmaps has proved a troublesome task in the past but it seems to be a problem reduced by the improvement of devices. Despite this surprise I cropped the image to be more suitable.


    You can see the app in action in the video below.

    The whole thing took around 30 minutes, with around 10 minutes project work and 20 minutes finding and editing the right images. Within 5 minutes I'd run Hello World.


    It's simple to create views using separate layout files for each display shape within Android's XML designer. Android wear comes with two screen types: Round, and Square - referred to in code as Rectangular. This proves as an interesting hurdle for design and development of an application. We're used to our screens having 90 degree corners and straight edges. We've grown used to developing applications that scale up and down in screen sizes. Now also a task presented iOS developers with the release of iOS 8.0 and Auto Layout. So sharing how we as Android developers overcome those issues has proven useful. It'll be interesting to see the different kinds of applications companies come up with to make use of Android Wear and wearables in general.

    Looking into the future I'm pleased to see that Google announced the possibility of offline music playing via bluetooth and GPS tracking. Meaning you're free to leave your phone at home whilst out for a run, walk or other activities. I'd be interested to see if they could bring offline maps to it too. As per their Android app functionality.

    Original post.

  • Announcing DevStat

    Mar 21, 2014

    After working on Android applications, amongst other things, for the best part of 2 years now I've found that there are some things that can prove rather helpful when trying to make the design images look good on a variety of screens. Android lets you do this rather easily, but in dealing with assets intended to serve both iOS and Android applications you're likely to use the retina, @2x, versions. By sticking with just this size as much as possible you can reduce the application size significantly, rather than having multiple files for each asset in your project. But sometimes they can look a bit jagged if compressed too far by the OS. So you may need to find out what the device screen density is to put a new, sharper image in place.

    I created DevStat to quickly see a device's details. So far the following are the details that can be seen.

    Google play link

    Screen Metrics
    Display density
    Drawable density
    Screen size


    Android version
    SDK Int
    OpenGL ES version


    Memory class
    Large memory class
    Maximum memory
    Free space
    Vibrator presence
    Autofocus availability

    The project is available on Github
    Feel free to add features if you like! I intend to add information relating to:

    • Camera(s)
    • GPS
    This was partly an exercise to see the functionality of the support action bar compatibility and to try a more pure gradle build script rather than adding gradle to a legacy project. I've not had a chance to test it on pre-4.0 devices, but it should hopefully work.