Best Practices for Android Developers We Follow at SoftwareHut

Best Practices for Android developers are the guidelines we follow to make better Android mobile apps.

As a software developer, you may often find yourself confused about an unexpected bug or other issue. But many of them can be avoided with some simple tips.

Thanks to them, your application will be as good as possible.

Today, I would like to present the best practices for Android developers that we use at SoftwareHut.

General Technological Concepts

If you don’t want to feel like an alien on the planet Earth in the Android world, you need to master these essential concepts:

Activity lifecycle

This is the point where you can decide what the user will see on his current screen. You need to know the ordering, differences and the purpose of the onCreate, onStart, onResume, onPause, onStop and onDestroy methods.

Remember that if you change the configuration or layout orientation, it will recreate the activity. Be aware of the fact that viewModels and savedInstanceState are methods that are meant to preserve state.

What’s more, the activity lifecycle is a familiar source of memory leaks.

Now, let’s move on to fragments, lifecycle and fragments transactions. Forget about using fragments if you don’t get fragment lifecycle and its transactions’ asynchronicity.

If you are embedding fragments, embed them into XML. Don’t forget about unsetting fragment listeners if you have stopped using them. Also, fragments shouldn’t be stored in a top-level list. Instead, you can clear it while destroying UI.

Do you know the cost of serialising objects to convert their state? Try storing item ID, and fetch it from the local database instead.

Fragment transactions are unpredictable – never use timer delays to wait for the fragment to be inflated.

Intents

The intent is an internal messaging concept. You can read more about ithere.

Material Design

Of course, this depends on the client, but using Google’s guide is recommended.

Key concepts:

Also, you need to have a good grasp of Java or Kotlin.

Code Quality

Java

We follow the best practices already written down in Google’s Java style guide.

Recommended books:

Android

Here you can find the best practices for Android developers.

Performance

Three simple steps to boost the performance of your Android application:

1. Don’t over-engineer optimisation.
2. Write correct, simple and concise code.
3. Run performance tests and look for bottlenecks.

Typical bottlenecks:

Frameworks and tools

Just two rules to remember in this section:

Libraries:

Architecture

Use clean architecture, period. Unless you are working on a project that you will throw away anyway. It doesn’t matter if you use MVP, MVC or MVVM. You know them well and what to expect of them.

Focus on keeping activities/fragments dumb, because they are only responsible for stuff related to android-view. Take a look at the example below:

Fun showHistoryOrder(historyOrder: Array)

Its job is to set items to the adapter and nothing more. Business logic rules should already be prepared in HistoryOrderItem. It’s not the actual API model object but rather its wrapper with additional properties – cancelVisible and deleteVisible.

The actual logic should be prepared in VM/Presenter/Controller. Using DataBinding reduces lots of boilerplate and simplifies the presentation layer. If you are using Android dependencies or third-party layers, wrap them with your class. In general, only imports visible in Controller/Presenter classes should be contextualised.

When implementing the model, separate the data source from the service class. The service’s only job is to deliver ready objects. The data source is just a dumb delivery boy doing what we ask him to do.

Best Practices for Android Developers

Animations

Be aware of the fact that using Handlers or Runnables can cause memory leaks. To animate views, use GPU-supported operations (translate, scale, etc.) instead of editing layout parameters. Invalidating a view tree is expensive.

Animations should be short – 100-200ms max.

The Material Design animation specifications – momentum, speed, weight and physics of objects – are another thing you should learn.

Working with background services

What about wake-locks? Be careful when acquiring them. If only one is needed, make sure that you release it in a final block. For scheduled operations, it’s better to use the firebase job scheduler. Unless time is critical in your application, it’s better to use an inaccurate time window for operations.

Memory leaks

Add square’s LeakCanary to the library.

Common sources of memory leaks are:

Adjusting to the device’s size

Have UI rules in mind – what should wrap the content and what matches the parent.

Don’t set a container’s size or the content’s size in dp. Otherwise, you risk inconsistency.

Setting padding is safe enough.

Don’t use separate layout resources for a view, unless this is necessary for building a proper tablet experience. If you will forget to test a view, you risk leaving a bug behind.

The minimum size of a clickable element is 48 x 48 dp.

Remember about the maximum and minimum size of image views as well as the fact that different devices have different screen resolutions.

Working with layouts

If you are looking at UI design, think of UIS as independent components. It’s better to group controls in reusable widgets than handling their actions separately in the activity.

Defensive programming

I don’t recommend doing it. The application should fail as quickly as possible during the development process. An error reporting service with different identifiers will help you with debugging and releasing builds. Nullcheck alone is not enough to fix nullpointer exceptions – think about why it’s null, which class causes it to fail, and respond accordingly.

Think about LifeCycled components – an operation may finish if the view is no longer available.

RxJava

Although Java is not a functional language, the Android world works great with the reactive streams concept. First, watch the introduction to rxJava.

Then read the rules written below: