1. Things Should Be Where They’re Supposed to Be (Strings, Colors)

There is tremendous growth in the Android ecosystem around the globe with a diverse community. People from different backgrounds, people with disabilities, people who wish to have fancy features like night mode, and more use Android apps in their day-to-day life.

Developing apps for such a diverse community is not an easy task. I’m not speaking about high-level architectures here. In contrast, it’s about simple things like strings, colors, dimens, etc. that will considerably affect modern Android development.

People usually feel comfortable using an application in their native language. The vital step is to maintain all the strings in a single file (usually strings.xml) to add different language-specific string files quickly.

This is also applicable to colors, dimens, and styles, so when you decide to do something like dark mode support or adjusting the layouts to tablet view, it’ll be easy to handle them. The bottom line is this: Maintain the code in a single place to reuse rather than hard-coding them wherever required.

2. Not Using Fragments

In the early days of Android development, it was recommended to use separate activities for each screen. Over time, developers faced different problems due to this. Also, activities being entry points to the application has been a vulnerability.

If you’ve been an Android developer for a while, then you’ll know that using activities made sense a couple of years ago when the Fragments API was not that mature.

Fast-forward to 2020, and the Android team recommends using fragments to design each screen and maintain single or few activities throughout the application to host fragments. It’s well known as Single Activity Architecture.

Following this architecture will reduce a significant number of interactions from outside the application. The new Jetpack navigation component is mainly based on Single Activity Architecture. The Fragments API will make your life much more straightforward. Maybe in a couple of years, Android development will shift from activities to fragments for the best.

3. Not Using Data Bindings or View Bindings

The Android development environment has been based on three types of files since the beginning: XML, Kotlin, and Java. XML files contain everything related to design, and Kotlin/Java files include anything other than the design part.

Eventually, UI and business logic needed to be linked, and that’s where data binding and view binding play a key role. The link between UI and business logic is started with the infamous findviewbyid function.

But view binding and data binding are the recommended solutions to solve this problem. The view binding’s primary purpose is to solve this linking problem with type and null safety at runtime.

Data binding is for the greater good. It allows you to bind UI components in layouts to data sources using a declarative format rather than programmatically.

4. Not Using Kotlin and Coroutines

It’s been a couple of years since Google announced Kotlin as the recommended language to develop Android apps. It was one of those transformational decisions: Kotlin solved the pain points in Java and can reduce the heavy lifting for developers.

Using Kotlin for Android development opened new gates with features like extensions, scoped functions, data classes, object keyword, null safety, etc. Apart from Android development, you can also enter multi-platform and server-side development with Kotlin.

Asynchronous programming plays a key role in mobile development. In the early stages, we used AsyncTask. Over time, RxJava came to light, and it’s a transformational change. But RxJava comes with a deep learning curve and a completely different approach with callbacks.

Then came coroutines, a Kotlin-y solution to asynchronous programming with a simple approach. These days, coroutines have been a standard solution to implement asynchronous tasks. The powerful features and simple implementation make it more adaptable.

Kotlin makes your development easy and concise, whereas coroutines allow you to execute asynchronous tasks sequentially without the need to learn anything new. Using them in your development only results in more productive and effective output.

5. Design Mistakes

Underestimating ConstraintLayout

ConstraintLayout comes with a combination of many handy features like guidelines, Barriers, Group, aspect ratio, flow, Layer, and more. With all these features, the ConstraintLayout can draw almost every single screen (from simple to complex use cases).

ConstraintLayout is different from Relative and Linear layouts. Stop treating them in the same way. We can create flat layouts without the nesting hierarchy. Flat layout design results in fewer layers to draw on the view.

Overuse of ConstraintLayout

Powerful features come at a risk of abusing them. Using ConstraintLayout in a UI that you can design with FrameLayout or LinearLayout is a ridiculous approach.

Fear of MotionLayout

ConstraintLayout is the right choice to design complex use cases, but not to implement animations and transitions. MotionLayout is an effective solution to do it.

MotionLayout is a subclass of ConstraintLayout that includes all of its outstanding features, and it’s fully declarative with the capability to implement complicated transitions in the XML. It is backward-compatible with API level 14, which means it covers 99% of use cases.

The new MotionLayout editor in Android Studio 4.0 makes it easy to work with MotionLayout. It provides a fancy environment to implement transitions, MotionScenes, and more.

MotionLayout is not something that includes complex calculations and algorithms. Instead, it’s a simple declarative approach to implement animations and transitions with a new fancy editor in Android Studio.

6. Not Being Aware of Security Flaws

Storing sensitive data

Storing sensitive data in the Android shared preference, database, or local storage is a risk. It can be hacked easily. Many developers are not aware of this and use a shared preference to store user sensitive data.

This can be solved using the new datastore library or Encrypted preference library or by implementing the encryption by yourself.

Secure communication

Many Android developers think that using HTTPS can make their communication with servers secure. But that’s not the case. Many hackers interfere with communications to mislead servers and clients. This is known as a middle man attack.

To establish a secure line to the server, we need to implement certificate pinning.

7. Not Being Aware of Android Studio’s Capabilities

It doesn’t matter how powerful a weapon is unless you learn how to use it properly. As developers, we are fortunate to have a powerful tool like Android Studio, but you should know how to use it productively.

There are many hidden features like handy shortcuts, live templates, file templates, predefined project structures, code generator plug-ins, customization, and more. We also have a database inspector, layout inspector, profiler, and more to be productive at runtime.

Android Studio also provides tooling support for several libraries such as a navigation editor to view an application’s navigation graph and a motion editor to implement effective animations and transitions in a fancy way.

8. Not Using Jetpack Libraries

“Jetpack is a suite of libraries to help developers follow best practices, reduce boilerplate code, and write code that works consistently across Android versions and devices so that developers can focus on the code they care about.” — Android Jetpack

JetPack libraries cover major features like paging3 for pagination, Room for the local database, WorkManager for long-running background tasks, DataStore for improved data storage, Hilt for DI, navigation component to navigate in the app UI, App Startup to reduce app startup time, and more.

All these libraries are built to keep performance and ease of use in mind to implement complex tasks with less code.

That is all for now. I hope you learned something useful. Thanks for reading!