Developing quality Android applications is hard and complex. The code we write has to be testable, robust and flexible enough to adapt to growth and changes. Android framework does not enforce us to write code in any specific architecture, which can be a good or a bad thing depends on our decisions.

How to develop a good Android application?

Couple years ago almost nobody cared about how to develop a good Android application. Nowadays, on the other hand, we have a lot of examples how to use MVP, Clean Architecture, VIPER but why should we care? Well, there are many important things we should be aware of.

Every application goes through a lot of change cycles and features addition and removal.

Every time you change something you should be able to test new functionality and also make sure your changes didn’t break any of the existing app features.

We should also keep in mind that we have to deal with many Android versions, screen sizes, orientations and finally device manufacturers.

Choosing the right application architecture can make dealing with all these challenges much easier but before we’ll dive into it, we should take care of some basics which will make our life much easier.

Basics of Android app architecture

Package structure

Instead of using layer structure like fragments, activities, adapters etc. you should package by feature. Grouping classes by feature provide higher level of abstraction, more readable and maintainable structure, easier code navigation and it’s much easier to scale.

For example, if you have DetailsActivity, DetailsFragment, DetailsListAdapter, DetailsItemModel you should put them in one package.

If you have a custom Application class make sure to put in in the top-level package.

File naming

Class files

Any class name should be created using UpperCamelCase, for example, ListActivity, DateHelper etc.

When a class extends an Android framework component it should always end with the component name, for example, ListActivty, ListFragment, ListAdapter etc.

Layour files

In the case of XML files names, you should always use lowercase letters and underscores, for example, activitybook, fragmentbook, item_book. It makes it clear as to what the layout is used for. Every layout file should be named starting with the name of Android component that it has been created for:

Activity – activity_

– activity_ Fragment – fragment_

– fragment_ Dialog – dialog_

– dialog_ Widget – view_

– view_ AdapterView item – item_

Drawable files

Drawable resources should be named using the corresponding prefix to make it clear to what exactly the item is used for. It will also help to group similar items.

Most common drawable types should use the following prefixes:

Icons – ic_

– ic_ Selectors – selector_

– selector_ Background – bg_

– bg_ Divider – divider_

– divider_ Progress – progress_

– progress_ Circle – circle_

To create selector state resources you should use the following suffixes:

Normal – _normal

– _normal Pressed – _pressed

– _pressed Focused – _focused

– _focused Disabled – _disabled

– _disabled Selected – _selected

Code style

The most important thing to remember about code style is the fact it should be shared across the developers who work together. Code style config file can be easily exported from Android Studio and used by other developers.

Strictmode

Android has a tool to catch many common platform-specific problems that bridge the gap between compilation errors and runtime crashes. StrictMode analyzes your application at the thread or virtual machine level and alerts you with potential problems.

To use strict mode all you have to do is some configuration in your custom application class. See the following example:

The above code enables all the checks, make sure to check StrictMode | Android Developers to understand what all the possible checks means and choose the most important ones for your application.

Building Android application

Android uses Gradle build system. It allows to manage dependencies, setting up different flavors of your application and many other useful things.

Gradle and Android plugin are independent of Android Studio so you can also build your application from the command line (it’s useful when you want to use continuous integration or a remote machine to build your apps).

To avoid dependency version mismatch define versions as project level properties. See the following example.

Top-level build.gradle file:

Module-level build.gradle file: