10 Common Programming Errors Made by Android Developers: Tips and Tricks for Success/

Android is a highly customizable, free, and rapidly growing platform that is available not just on mobile phones or tablets, but also on smartwatches, TVs, and cars. With the latest Lollipop update, Android programming continues to improve and the platform has matured significantly since its initial release. However, with thousands of different devices on the market, each with different screen sizes, chip architectures, hardware configurations, and software versions, segmentation is the price of openness. Unfortunately, this segmentation can cause thousands of ways your app can fail on different devices, even for experienced Android programmers. This guide highlights the top 10 most common mistakes made by Android developers and provides tips on how to avoid them.

1. Developing for iOS

One of the most common mistakes made by Android developers is creating an iOS clone for their Android app. Although iOS design standards may have been considered the gold standard at one time, users have grown accustomed to the Android platform, and pushing iOS design standards to them can be detrimental to the user experience. Unless there is a super good reason for breaking the guidelines, don’t do it.

2. Developing for Your Android Device

Unless you are building a kiosk/promo app for a single tablet, it is unlikely that your Android app will look good on every device. Different devices have different screen sizes, densities, and orientations, and resources are included multiple times to account for these variations. To ensure your app looks and functions well on all devices, use density-independent pixels (dp) and test on multiple devices using the Android emulator or Genymotion.

3. Not Using Intents

Intents are a key component of Android programming, allowing you to pass data between different parts of the app or different apps on the system. Always use Intents for sharing content, taking pictures, recording video, picking contacts, adding events, opening links with native apps, and other scenarios. Unless there is a good reason to make a custom implementation, always use Intents for these scenarios.

4. Not Using Fragments

Fragments are separate building blocks with their own (rather complex) life cycles that exist inside an Activity. They help optimize various screen sizes, can be easily managed by their parent activity, and can be reused, combined, and positioned at will. Unless you want to dig deep into the Android core, use fragments whenever possible.

5. Blocking the Main Thread

The main thread is responsible for keeping the user interface responsive, and blocking it can cause significant delays, leading to frustrated users. To minimize blocking the main thread, always use worker/background threads for network calls, bitmap loading, image processing, database querying, and SD reading/writing.

6. Reinventing the Wheel

Another common mistake that Android developers make is trying to reinvent the wheel. Many developers waste a lot of time writing code for common tasks that have already been solved. For instance, network calls, image loading, database access, JSON parsing, and social login are some of the most common tasks in any app, and there are existing libraries that can handle these tasks efficiently.

Instead of writing code from scratch, it is better to utilize existing libraries that have been written, tested and used widely. Examples of such libraries include Retrofit and Volley for network calls, Picasso for image loading, Gson and Jackson for JSON parsing, and common implementations for social login. This way, you save time and focus on creating the best user experience.

7. Not Assuming Success

Even when you use well-documented libraries to handle long-running tasks, there is always a possibility that a task may fail. For instance, network calls can take longer than expected, packages can get lost, and there can be network failures. However, successful network calls are far more likely than unsuccessful ones.To enhance the user experience, it is better to assume success and handle failure. For example, when a user likes a post, the like count should be immediately increased, and in case the call fails, the user can be notified. Immediate feedback is expected in the modern world, and apps must accommodate the user’s psychology.

8. Not Understanding Bitmaps

Images are a popular type of content in Android apps. However, images consume a lot of memory, and loading an image into memory is a resource-intensive process. Before displaying an image on the screen, it has to be loaded into memory, and bitmaps are the most common way to do this.

To display images efficiently, you need to follow Android programming tips. For instance, you should measure the view you’re showing your images in, scale or crop the large image accordingly, and show only what can be displayed. If you don’t do this, your app can consume a lot of memory, leading to slow performance or even app crashes.

9. Using Deep View Hierarchy

Layouts have an XML presentation in Android, and in order to draw content, the XML needs to be parsed, and the screen needs to be measured. This process can be time-consuming and resource-intensive, and it needs to be optimized.

For example, if you want to make a 3×3 grid with images, one way of doing this is using a vertical LinearLayout containing 3 LinearLayouts with equal weight, each of them containing 3 ImageViews with equal weight. However, this approach can lead to a warning that “nested weights are bad for performance.”

A better way to avoid this mistake is by using RelativeLayout or GridLayout. These layouts can efficiently replace the nested LinearLayouts, leading to better performance and a more responsive user interface.

10. Not Setting the minSdkVersion to 14

Finally, many Android developers make the mistake of not setting the minSdkVersion to 14. Android 2.x was a significant milestone in developing this platform, but some things should be left behind. Supporting older devices adds more complexity for code maintenance and limits the development process.

While there may be some big markets with old devices, such as India, setting the minSdkVersion to 14 means leaving out a couple of million users without their favorite social network. However, if you are starting fresh and trying to create a beautiful experience for your users, it is essential to consider eliminating the past. Users who don’t have the resources or feel the need to upgrade their device or operating system won’t have the incentive to try out a superior version of your Android app and ultimately spend money on it.