10 Most Common Top Mistakes That Android Developers Make: A Programming Tutorial

Android. What’s not to like about this platform? It’s free, it’s customizable, it’s rapidly growing and it’s available not just on your phone or tablet, but on your smartwatch, TV and car too.

With the latest Lollipop update, Android programming continues to improve. The platform has matured quite a bit since the initial AOSP release, and set the user expectations bar quite high. Look how good the new Material design pattern looks!

There are thousands of different devices, with different screen sizes, chip architectures, hardware configurations, and software versions. Unfortunately, segmentation is the price to pay for openness, and there are thousands of ways your app can fail on different devices, even as an advanced Android programmer.

Regardless of such huge segmentation, the majority of bugs are actually introduced because of logic errors. These bugs are easily prevented, as long as we get the basics right!

Here’s an Android programming tutorial to address the 10 most common mistakes Android developers make.

Learn Android programming at a more advanced level with this tutorial.

 

Common Mistake #1: Developing for iOS

To my great pleasure, this Android mistake is far less common nowadays (partially because clients are beginning to realize that the days when Apple was setting all the design standards are long gone). But still, every now and then, we see an app that is an iOS clone.
Don’t get me wrong, I’m not an Android programming evangelist! I respect every platform that moves the mobile world a step forward. But, it’s 2014 and users have been using Android for quite a while now, and they’ve grown accustomed to the platform. Pushing iOS design standards to them is a terrible strategy!
Unless there is a super good reason for breaking the guidelines, don’t do it. (Google does this all the time, but never by copy-pasting.)
Here are some of the most common examples of this Android mistake:

1. You should not be making static tabs, and they don’t belong on the bottom (I’m pointing at you Instagram).
2. System notification icons should not have color.
3. App icons should not be placed inside a rounded rectangle (unless that’s your actual logo ex. facebook).
4. Splash screens are redundant beyond the initial setup/introduction. Do not use them in other scenarios.
5. Lists should not have carets.

These are just a few of the many other small things that can ruin the user experience.

Common Mistake #2: Developing for Your Android Device

Unless you are building a kiosk/promo app for a single tablet, chances are your Android app won’t look good on every device. Here are a few Android programming tips to remember:

• Density-independent pixels (dp) are different than normal pixels (px).
• Resources are included multiple times to account for different densities and orientations.
• 9-patch drawables are stretched to fit the screen.

There are literally thousands of possible scenarios, but after a while you develop a sense for covering them all with a handful of cases.
You don’t own thousands of devices? Not a problem. The Android Emulator is super good in replicating physical devices. Even better, try out Genymotion, it’s lightning fast and comes with a lot of different popular preset devices.
Also, have you tried rotating your device? All hell can break loose…

Common Mistake #3: Not Using Intents

Intents are one of Android’s key components. It’s a way of passing data between different parts of the app or, even better, different apps on the system.
Let’s say you have a gallery app that can share a download link to some images via SMS. Which of the two options seems more logical?
Option 1:

• Request the SEND_SMS permission.
  

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

• Write your own code for sending SMS using the SmsManager.
• Explain to your users why your gallery app needs access to services that can cost money, and why they have to grant this permission to use your app.

Option 2:

• Start an SMS Intent and let an app designed for SMS do the work
  

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

In case that you have any doubts, best solution is option 2!
This approach can be applied to almost anything. Sharing content, taking pictures, recording video, picking contacts, adding events, opening links with native apps, etc.
Unless there is a good reason to make a custom implementation (ex., a camera that applies filters), always use Intents for these scenarios. It will save you a lot of programming time, and strip the AndroidManifest.xml of unnecessary permissions.

Common Mistake #4: Not Using Fragments

A while ago in Honeycomb, Android introduced the concept of fragments. Think of them as separate building blocks with their own (rather complex) life cycles that exist inside an Activity. They help a lot with optimizing for various screens, they are easily managed by their parent activity, can be reused, combined and positioned at will.
Launching a separate activity for each app screen is terribly inefficient, since the system will try to keep them in memory as long as it can. Killing one won’t free the resources used by the others.



Unless you want to dig deep into the Android core and read this article, advocating against fragment usage, you should use fragments whenever possible. It basically says that fragments and cursor loaders have good intended purpose, but poor implementation.

Common Mistake #5: Blocking the Main Thread

The main thread has a single purpose: keeping the user interface responsive.
Although the science behind measuring the frame rate our eyes/brain can perceive is complex and influenced by a lot of factors, a general rule is that anything below 24 fps with delay greater than 100 ms won’t be perceived as smooth.
This means that the user’s actions will have a delayed feedback, and the Android app you have programmed will stop responding. Stripping the user of his control over the app leads to frustration, frustrated users tend to give very negative feedback.
Even worse, if the main thread is blocked for a while (5 seconds for Activities, 10 for Broadcast Receivers), ANR will happen.




This was so common in Android 2.x, that on newer versions the system won’t let you make network calls in the main thread.
To avoid blocking the main thread, always use worker/background threads for: 1. network calls 2. bitmap loading 3. image processing 4. database querying 5. SD reading / writing

Common Mistake #6: Reinventing the Wheel

“OK, I won’t use the main thread. I’ll write my own code that communicates with my server in a background thread.”
No! Please don’t do that! Network calls, image loading, database access, JSON parsing, and social login are the most common things you do in your app. Not just yours, every app out there. There is a better way. Remember how Android has matured and grown as a platform? Here’s a quick list of examples:

1. Use gradle as a build system.
2. Use Retrofit / Volley for network calls.
3. Use Picasso for image loading.
4. Use Gson / Jackson for JSON parsing.
5. Use common implementations for social login.

If you need something implemented, chances are it’s already written, tested and used widely. Do some basic research and read some Android programming tutorials before writing your own code!


To follow us on twitter click @iReporterng

To Like our facebook fan page click iReporter on Facebook
Join Us on BBM Channel Add Pin or click: C00224051
Report News as its UNFOLDS via: ireporterng@gmail.com