Ensuring quality as an Android developer

Published on 1 October 2013

Illustration of five golden stars in a row with a hand cursor selecting the final star, representing a top rating

Android devices come in all shapes and sizes. It is estimated that there are almost 4000 distinct Android devices.

Within this wide range of devices there are different screen sizes, vastly different hardware performance levels and OEMs creating custom ROMs. In addition there are several different versions of the Android OS concurrently active at any time. This results in several layers of fragmentation and means that testing and ensuring your app works across the board can be a complete nightmare.

This combined with the fact that there is no enforced app approval process on the Google Play store, resulted in many low quality apps being released.

So the question I am often asked is how do I ensure quality?

1. Know your market

Whilst there are thousands of Android devices worldwide, not all of them will be readily available in your region. For example there is often little point supporting a exotic only available in China device when your target market is UK where the device is nigh on impossible to get hold of.

Furthermore, to prevent a poor UX and subsequent bad reviews, only allow your app to be downloaded by intended devices. This can be controlled by the Google Play developer console.

2. Unit testing and Test-Driven development

Unit testing is quite common practice in most software houses nowadays. It provides the benefits of clean and maintainable application logic along with documentation on how your code is supposed to behave.

The standard Android Unit Test framework can be painfully slow as it relies on a Android Emulator or device. Therefore I tend to prefer robolectric as it runs the tests within the JVM on your workstation in seconds.


3. Avoid hard coded position values


Any Android developer will tell you that using hard coded position values are bad due to the large number of different screen sizes and densities. Instead specify layout values in density independent pixels (dips) which allows the Android OS to scale the values up or down to that device.

Also, make use of Drawable resources. Such as nine-patch which is a stretchable PNG that can easily be resized and a ‘Shape’ drawable that can be used to create complex resizable geometric shapes using xml.

4 Build a comprehensive test plan

A solid methodology is required to properly test Android apps. The testing plan must be owned by the Android development team and testers should be involved with the team from day one. The team should have a good range of physical Android devices to test on.

5 Thoroughly test In-App purchase mechanism

Something I often encounter is development teams failing to adequately test their In-App purchase mechanism end-to-end. Often I put this down to the latency involved with completing a single test, as this requires the app to be uploaded to the Google Play store, a process that can take up to 24 hours for the app to completely propagate. Worse still, I’ve seen this left until release day to do, which leaves no time to properly fix any issues that may arise.

As this is code that controls the monetization of your app it is important to get it right. The last thing you want are lots of disgruntled users who have paid for content that they cannot access and subsequently leaving lots of negative reviews. Therefore it is important to have a strategy for testing this and leave plenty of time to ensure it works correctly.

Whilst there is no substitute for having a stockpile of real test devices alongside a team of dedicated testers, there do exist many Remote Testing labs that will allow you to test your app on a wide range of devices and configurations.

One of the better services I have come across is AppThwack, which uses the most popular real devices and allows you to add custom tests.