Best practices in Android Development

Best practices in Android Development

Android is currently the most used OS across the world. The popularity of android applications is at a pick. As a developer, our duty is to provide applications with the best performance and innovative features.

To achieve this, the developer must follow certain standards in the application development process. In this article, you will find some useful tips and rules to develop an android application.

Development Tool and Android SDK

Use the Google-recommended Android studio as your development tool. It is very fast and improved than other tools like eclipse etc. Place your android studio and sdk in the same directory to avoid reinstalls of components and make sure that the location has all the admin (read/write) permissions to avoid issues.

Build system

The default option must be Gradle using the Android-provided Gradle plugin.

It’s important to define the application’s build process in Gradle files, rather than being reliant on IDE-specific configurations. This is helpful for consistent builds between tools and better support for continuous integration systems of your projects.

In a project structure, Gradle offers a large degree of flexibility in your project structure, unless you have a compelling reason to do otherwise, you should accept its default structure as that simplifies your build scripts.

MinSdkVersion: 21. Please check Android version charts before deciding minimum api for a project. There are different statistics for different regions. It is important to mention that some material design features are available on Android 5.0 (API level 21) and above. Hence, from API 21, the multidex support library is not needed anymore.

In Place of (shell, Python, Perl, etc) scripts, you can make tasks in Gradle. Just follow Gradle’s documentation for more details. Google is providing many helpful Gradle recipes, specific to Android.

Product Flavours

Product flavor is a very good feature provided by Google. This would be very helpful when you have different versions for different users. For example, if you are a free and paid version or a different version for admin and normal users. Instead of providing conditions inside code, use the product flavor feature in the application.

Code Re-Usability

This is a very important topic in the context of java code files and xml files. There must be many API calls in the application to achieve different functionalities.

Instead of writing each code every time, make some generalize class for API call and with the help of interfaces, use them across the applications. Two main benefits of using this, Reduction of time and any further modification in code will be very easy.

Use <include/> tag in xml (design) file to reuse layouts in different activities and fragments. For example, to create the same header and footer for each screen, create save, yes, no, cancel button style for while application.


The application includes many static strings. Define all strings at one place called “String.xml”. This can help at the time of localizations (when application will be made for more than one language). Make different values folder for each language, which you need to support in application. Make sure to add strings in string files with better naming conventions. Below is an example:



For margins and paddings, “dimens.xml” must be used.

Just like colors.xml, use dimens.xml. Also add a “palette” of spacing and font sizes, below is example of a dimens file:

Application Icon

Add application icons in mipmap folder instead of drawable folders. At the time of building application for different resolutions, drawable icons will be stripped.

Application images

Android provides very good drawable folder structures (Like hdpi-drawable, xhdpi-drawable, xxhdpi-drawable, xxxhdpi-drawable) for adding images for multiple resolutions. You need to add some images or icons in the respected folder according to their resolutions. Below is the screen sizes list with the respective drawable folder.

hdpi – 480*800

xhdpi – 720*1280

xxhdpi – 1080*1920

xxxhdpi – 1440*2560

Although android providing a very good facility for storing or adding icons and images for different resolutions, we must need to use shapes and selector files instead of adding images for every design element. This will help us to reduce application size and faster performance.

Layout Design

To improve application speed, avoid deep level hierarchy inside layout. Deep level of hierarchy of views will directly affect UI speed and smoothness. Try to use Relativelayout instead of LinearLayout. Below is a very good example:

Scenario 1: Using linear layout

Scenario 2: Using relative layout

Second example will be preferable over first one.

Another very good introduction for layout design is constrained layout. Try to use as much as possible. Constrain layout giving the best performance when we are making apps for different resolutions.

Use External Libraries

Many open-source and free external libraries are available online. Some of them are very optimized and powerful. Developer needs to use this when it’s required. Below are powerful libraries, which will be very helpful.

For Network/API calls: Volley, Retrofit

Parsing Json response: GSON

Load image from server/lazy loading: Picasso, Glide

Dependency Injection: Dagger2

View Injection: Butterknife

Chart integration: Mpchart

Analytics: Firebase

Google play service is also very good libraries from google but remember, don’t add whole play service package. Just add packages, which you want to use.

Proguard configuration

ProGuard is helpful on applications to shrink the packaged code.

It is configure Gradle to use ProGuard when building a release APK. Below is the example:

In order to determine which code has to be preserved and which code can be discarded or obfuscated, you have to specify one or more entry points to your code. Entry points are classes with main methods, activities, midlets, applets, etc. Android is using the default configuration, which could be found from SDK_HOME/tools/proguard/proguard-android.txt. Using the above details, custom project-specific ProGuard rules, as defined in my-project/app/, will be appended to the default configuration.

A major problem related to ProGuard is to see the application crashing on start with ClassNotFoundException or NoSuchFieldException or similar, even the build command (i.e. assembly release) is succeeded. This means one of two things:

ProGuard removed the class, enum, method, field or annotation, considering it is not required.

ProGuard renamed the class, enum or field name, but it is being used indirectly by its original name, i.e. through Java reflection.

Pay Attention to app/build/outputs/proguard/release/usage.txt to see if the object in question has been removed or not. Pay Attention to app/build/outputs/proguard/release/mapping.txt to see if the object in question has been obfuscated or not.

Prevent ProGuard from stripping away will need classes or class members, add keep options to your ProGuard config:

-keep class com.futurice.project.MyClass { *; }

Prevent ProGuard from class members or obfuscating classes, add a keepnames:

-keepnames class com.futurice.project.MyClass { *; }

Content Providers

When we need to store a large amount of data, SharedPreferences are not enough, we need to use platform-standard content providers, which are fast and process safe.

Problem with ContentProviders is the amount of boilerplate code that is needed to set them up, as well as low-quality tutorials. We cannot find good content or blogs on the internet.

It is possible, however, to generate the ContentProvider by using a library such as Schematic, which significantly reduces the effort.

The other option is database Sqlite with creating tables and columns. It is possible to serialize the data objects, for instance with Gson, and only persist the resulting string.

In this way file base data storage system, you lose in performance but on the other hand, you do not need to declare a column for all the fields of the data class.

Memory Leaks

LeakCanary is the very good external library that makes runtime/live detection and identification of memory leaks a more routine part of your application development process. Just remember to configure only the “no-op” dependency in your release build. To make applications optimized for battery consumption, this is the best library to include in our project.

 Important small points!

  • Use parcelable class instead of serializable at the time of sending data in bundles
  • Use AsyncLoader instead of Asynctask
  • Don’t perform heavy task on the main thread
  • Use intent service instead if service where it’s possible
  • Use Expresso for unit testing
The following two tabs change content below.
I am a Mobile Application developer at DEV IT. Working towards challenging and high-performance oriented roles in the field of Computer engineering has helped me to gain expertise and experience to develop complex projects with efficiency.

2 thoughts on “Best practices in Android Development

Leave a Reply

Your email address will not be published. Required fields are marked *