Let’s be real, what’s not to love about Android? It’s a free and flexible operating system that’s rapidly growing and goes beyond just your phone or tablet, extending its reach to smartwatches, TVs, and even cars.

The latest update, Android Lollipop](http://www.android.com/versions/lollipop-5-0/), along with [Android programming continues to improve. The same is true of Android programming software, tools, and resources. The platform has matured quite a bit since the initial AOSP release, really upped the game in terms of user experience. Just take a look at the sleek new Material design!

However, the open nature of Android comes with a cost: fragmentation. There are thousands](http://opensignal.com/reports/fragmentation.php) of Android devices out there with different specs, screen sizes, hardware, and software versions. This means there are countless ways your app could malfunction on different devices, even for seasoned Android developers.

Despite this, most bugs stem from simple logic errors in your code. The good news is that by focusing on the fundamentals, these issues can be easily avoided.

This Android programming tutorial highlights 10 common Android development pitfalls to help you write cleaner, more robust code.

Common Mistake #1: Designing with iOS in Mind

Thankfully, this isn’t as common as it used to be, partly because developers are realizing that Apple isn’t the sole design authority anymore. However, we still see apps that feel like iOS replicas.

Don’t get me wrong, I have nothing against iOS. Every platform that pushes mobile technology forward deserves respect. But it’s 2014, and Android users have become accustomed to the platform’s unique design language. Imposing iOS design principles on them is a disservice to your users.

Unless there’s a compelling reason to deviate from the guidelines, stick to it. (Even Google does this occasionally, but they don’t just copy-paste.)

Here are a few prevalent examples of this oversight:

1. Avoid using static tabs, especially at the bottom of the screen (looking at you, Instagram).
2. System notification icons should remain colorless.
3. App icons should not be confined within rounded rectangles (unless that’s your logo, like Facebook).
4. Splash screens serve a purpose during the initial setup or introduction. Avoid using them elsewhere.
5. Lists don’t need carets in Android.

These seemingly many other details can significantly impact the user experience.

Common Mistake #2: Developing for Your Own Android Device

Unless you’re building an app for a single tablet or kiosk, your app probably won’t look great on every Android device. Here’s why:

• Density-independent pixels (dp) are not the same as standard pixels (px).
• Resources exist in multiple versions to accommodate different screen densities and orientations.
• 9-patch drawables are stretched to fit various screen sizes.

While there are numerous possibilities, experience will teach you how to address them effectively with a handful of cases.

Don’t own countless devices? No worries. The Android Emulator does a fantastic job of mimicking real devices. For even better performance and pre-configured device profiles, check out Genymotion.

And remember to rotate your device during testing. Things can get messy quickly!

Common Mistake #3: Neglecting Intents

Intents are fundamental to Android development. They allow you to exchange data between app components or even different apps.

Imagine you have a gallery app that lets users share image download links via SMS. Which approach makes more sense?

Option 1:

• Request the SEND_SMS permission.

  1	<uses-permission android:name="android.permission.SEND_SMS" />

• Write custom code for sending SMS messages using SmsManager.

• Explain to users why your gallery app needs access to potentially costly services and why they need to grant this permission.

Option 2:

• Use an SMS Intent and let an SMS app handle the sending process.

  1 2 3 4

  Intent sendIntent = new Intent(Intent.ACTION_VIEW); sendIntent.setData(Uri.parse("sms:" + telephoneNumber)); sendIntent.putExtra("sms_body", x); startActivity(sendIntent);

When in doubt, option 2 is the way to go!

This principle applies to many scenarios like content sharing, photo and video capture, contact selection, event creation, and opening links with native apps.

Unless a custom implementation is essential (e.g., a camera app with real-time filters), always leverage Intents for these tasks. You’ll save development time and reduce unnecessary permissions in your AndroidManifest.xml.

Common Mistake #4: Overlooking Fragments

Introduced in Honeycomb, fragments are like modular building blocks with their own (somewhat complex) lifecycles, residing within an Activity. They’re invaluable for screen optimization, easy management by the parent Activity, and can be reused, combined, and positioned as needed.

Launching separate activities for each screen is incredibly inefficient. The system tries to keep them in memory, even after they’re no longer needed. Closing one won’t free up the resources consumed by others.

Unless you’re delving deep into Android’s internals and subscribe to the arguments outlined in this article (which advocates against fragment use), you should utilize fragments whenever feasible. This document suggests that while fragments and cursor loaders have noble goals, their implementation leaves something to be desired.

Common Mistake #5: Blocking the Main Thread

The main thread has one job: maintaining a smooth and responsive user interface.

While the science behind our perception of frame rates is complex, a general rule is that anything below 24 frames per second with delays exceeding 100 milliseconds will feel choppy.

Delays translate to sluggish feedback for the user, making your app feel unresponsive and frustrating to use, ultimately leading to negative reviews.

Worse yet, if the main thread remains blocked for an extended period (5 seconds for Activities, 10 for Broadcast Receivers), the dreaded ANR will occur.

This was so common in Android 2.x that newer versions prevent you from performing network calls on the main thread.

To keep the UI responsive, always offload these tasks to worker/background threads:

1. Network requests
2. Bitmap loading
3. Image processing
4. Database queries
5. SD card reading/writing

Common Mistake #6: Reinventing the Wheel

“Okay, I won’t use the main thread. I’ll write my own code to handle server communication in a background thread.”

Please, don’t! Network communication, image loading, database access, JSON parsing, and social logins are common tasks across almost all apps. And thankfully, Android’s maturity means there are better ways. Here are a few examples:

1. Use gradle as your build system.
2. Utilize Retrofit / Volley for handling network requests.
3. Leverage Picasso for efficient image loading.
4. Employ Gson / Jackson for parsing JSON data.
5. Simplify social logins with common implementations.

If you need a specific functionality, chances are someone has already written, tested, and widely used a solution for it. Before writing your own code, do some research and explore existing Android programming tutorials and libraries.

Common Mistake #7: Waiting for Confirmation

Excellent! We’ve learned to delegate long-running tasks and use established libraries. However, users will inevitably experience some waiting time. Data transmission and processing are not instantaneous – there are round-trip delays, potential network issues, and lost packets.

But this waiting time can be managed. Successful network requests are statistically far more likely than failures. So why wait for server confirmation before handling a successful request? It’s far better to assume success and handle potential failures gracefully. For example, when a user likes a post, the like count increases instantly. If, in the unlikely event the request fails, the user is notified.

In today’s fast-paced world, instant feedback is expected. People dislike waiting. Apps need to adapt to this user psychology.

Common Mistake #8: Misunderstanding Bitmaps

Users love engaging content, especially when it’s visually appealing. Images, for instance, are fantastic for conveying information but they also consume significant memory – and I mean significant!

Before appearing on screen, images need to be loaded into memory. Since bitmaps are commonly used for this, let’s break down the process:

Let’s say you want to display a picture from your camera. The total memory required is: memory_needed_in_bytes = 4 * image_width * image_height;

Why 4? The recommended bitmap configuration is ARGB_8888, which allocates 8 bits (1 byte) per pixel for alpha, red, green, and blue channels for accurate display. Alternatives like RGB_565 halve the memory usage but compromise transparency and color accuracy, potentially introducing a green tint.

Imagine you have a new device with a Full HD screen and a 12MP camera. A 4000x3000 pixel photo requires: 4 bytes * 4000 * 3000 = 48 MB

That’s a whopping 48MB of RAM for a single image!

Consider the screen resolution. You’re attempting to display a 4000x3000 image on a 1920x1080 screen. In a worst-case scenario (full-screen display), you shouldn’t allocate more than 4 * 1920 * 1080 = 8.3 MB.

Always follow these Android programming best practices for displaying bitmaps efficiently:

1. Measure the view where your image will be displayed.
2. Scale or crop the image accordingly.
3. Display only what’s visible within the view.

Common Mistake #9: Creating Complex View Hierarchies

Layouts in Android are defined in XML. Before content can be drawn, this XML needs to be parsed, the screen measured, and elements positioned. This process is both resource and time-intensive and needs optimization.

This is where the ListView (and more recently, the RecyclerView) comes in.

While the system reuses inflated layouts, the initial inflation process still needs to occur.

Let’s say you want to create a 3x3 image grid. One approach is to use a vertical LinearLayout with three equally weighted LinearLayout children, each containing three equally weighted ImageViews.

The problem? You’ll receive a warning that “nested weights are bad for performance.”

Remember this saying (which I just made up): “With a little effort, all hierarchies can be flattened.”

In this scenario, a RelativeLayout or GridLayout can replace the nested LinearLayouts for greater efficiency.

Common Mistake #10: Not Setting minSdkVersion to 14

While not technically a mistake, it’s considered bad practice.

Android 2.x was a significant step forward, but some things are best left behind. Supporting older devices adds complexity to code maintenance and limits your development options.

The numbers are clear: users have moved on, and so should developers.

Of course, this might not be feasible in markets with a large user base on older devices (e.g., India). Setting minSdkVersion to 14 for the Facebook app would mean excluding millions of users. However, if you’re starting fresh and aiming to deliver an exceptional experience, consider focusing on the present and future. Users who haven’t upgraded their devices or OS are less likely to try a superior version of your app or spend money on it.

Wrap Up

Android is a powerful and rapidly evolving platform. While expecting users to keep pace with every update might not be realistic, it’s essential for Android developers to stay ahead of the curve. Mastering the fundamentals and avoiding common pitfalls is paramount before tackling complex projects.

Understanding that Android extends beyond phones and tablets is crucial. It’s on our wrists, in our living rooms, kitchens, and even cars. A strong grasp of the ecosystem and access to more advanced Android tutorials will equip you to build apps for diverse hardware and use cases – from high-end smartphones to simple smart home devices.