11 mistakes I made in 2 years of Android app development which you should be avoiding…

Scroll this

For 2 years I have been dipping myself in Android app development, and though I have progressed a lot, there were a lot of naive mistakes that I have made along the way.

When you are learning on your own following tutorials on the internet, it’s common to make mistakes especially if you’re a rookie. But as the saying goes, you learn from your mistakes and that’s when you make significant progress.

So, doesn’t matter if you’re new to Android app development or an experienced one, be aware that you’re not consciously or unconsciously making these mistakes that I had made.


Being late to the party

I so wish I would have started learning Android app development much earlier, there’s so much to learn and it keeps on growing with every passing day. Believe me, if you’re hesitating to start now, just do it, there’s no better time to start than now.

Also, if you’re familiar with JavaScript and getting those negatives vibes from learning Java, you can create Android apps by using Facebook’s React Native extension at the comfort of your JS knowledge.

If I must start somewhere, right here and now is the best place imaginable.” ― Richelle E. Goodrich


Cramming up everything in Activity or Fragment

When you’re starting off, it’s very common to write everything, every method inside a single Activity or a Fragment, I did it too and the result? One hell of a messy codebase.

Split your UI elements into individual views or widgets and handle changes for the element inside the class for that element. Create utility classes and shift appropriate utility methods to those classes instead of lining up methods in the Activity or Fragment.

Not only this makes your code look cleaner, but also increases reusability of your elements and methods, which ultimately saves time in the future.

“It is not the language that makes programs appear simple. It is the programmer that make the language appear simple!” ― Robert C. Martin


Not using Source Control for your codebase

This is one of the most common mistake a rookie can make. Taking frequent backups of your codebase into a flash drive or external hard disk can be both painful and unsafe, as you can forget to take backups or lose your entire code over some petty mistake.

Start using Github or Bitbucket to safely store your Android project and the incremental changes you make over time.

While I personally prefer and recommend Github, if you are unwilling to pay the monthly fees for Github, you can either apply for a student pack (if you’re one) or use Bitbucket, which is anyways free for up to 5 members in a team.

“Safety is a cheap and effective insurance policy.” — Unknown


Too much nesting in layouts

Android suffers from rendering layouts which have too much nesting in it, as the system has to traverse every level and render the whole stuff accordingly. While this might not be a problem in most cases, but optimizing your layouts ensures that your app layouts render with the least latency.

When writing XMLs for a layout, know which ViewGroup to harness so that you can achieve your requirements by using the minimum possible nesting. A very simple and common example is you can for most cases convert a LinearLayout to a RelativeLayout by making proper use of positioning of elements inside the layout, rather than having 2–3 levels deep of LinearLayout for the same effect.

“Deleted code is debugged code. ”— Jeff Sickel


Hardcoding strings in XML and Java code

It’s easy to be lazy and put down strings in XML layout or in Java code while setting any text for a TextView or EditText hint. While this approach gets you through most cases without any issue, you will repent when you’ll have to change some shared text or make your app speak more than one language.

From the very beginning develop the habit of putting down strings in the general strings.xml or on separate strings.xml for each language if you’re supporting multiple languages, this gives you the flexibility to control your strings with minimal effort.

“Flexibility is the greatest strength.” ― Steven Redhead


Not being aware of the latest API changes

Android is ever changing, and so are their APIs. So to make sure that your app works properly for every user, you need to aware of the changes that are made to the existing APIs.

A classic example of this is the AlarmManager API, it has been changed in API level 19 (KitKat) to make alarms scheduling inexact as compared to being exact in the previous versions. It changed again in API level 23 (MarshMallow) to support Doze.

So, if you miss out on these optimizations, there’s high chance that your alarms won’t be scheduled properly and your users might miss out that notification or your Service might not run when it was scheduled to.

“Well, the rollout of new technology always affects how wizards do business.” — Diane Duane


Not doing extensive testing after bumping up targetSdk

In the last time, I was talking about how Android changes after almost every new release. Sometimes the changes are so radical that it might break your app if you didn’t handle the changes properly in your app.

Remember when Android introduced runtime permissions in MarshMallow? Well, what would have happened if you just bumped up your targetSdk from 21 or 22 to 23 without asking explicitly for runtime permission in your code and hoped your app would run fine?

Yeah, you might have guessed that right, your users would be seeing that nice and short message “Unfortunately, AppName has stopped working”.

This happens because when your app in targeting a lower SDK level, Android assumes that your app isn’t optimized for the new changes, and thus won’t enforce any checks on that. However, when you have updated to the new SDK level, you’re confirming that your app complies to the changes made to the new level. I wrote my experience regarding this on the freeCodeCamp blog.

“There’s no harm in hoping for the best as long as you’re prepared for the worst.” ― Stephen King


Ignoring memory leaks in your app

Android or any operating system is a shared ecosystem, where every app should behave like a good citizen and don’t gobble up device memory like a dinosaur.

The best way to ensure this behavior is to make sure that your app has no or the very least memory leaks. A very common mistake is creating static references to a whole Activity or a Fragment. This creates a huge memory leak as the system holds the entire Activity or Fragment reference even when it’s not required.

There are other numerous small and big memory leaks that occur if you haven’t done your homework well. Fortunately, our friends at Square has created a library called LeakCanary to detect all sorts of memory leaks so that you can develop an airtight app without breaking yourself.

“A small leak will sink a great ship.” — Benjamin Franklin


Handing out your codebase on a silver platter

In case you haven’t heard of APK decompiling then you’re in for a surprise. If your app’s code isn’t well protected and obfuscated then it’s pretty damn easy to reverse engineer your app with free tools available online.

This leads to either competitor getting hold of your business logics, or hackers trying to find exploits on your app.

Android Studio offers ProGuard, a free tool to obfuscate your codes based on some rules that you apply. With ProGuard on, your code will look gibberish to people trying to reverse engineer your APK.

Since ProGuard is a free tool, it’s only powerful to an extent. However, it’s big brother DexGuard tightly seals down your app to even the most brutal attackers, but it comes with a hefty price tag.

“Hardware is easy to protect: lock it in a room, chain it to a desk, or buy a spare. Information poses more of a problem. It can exist in more than one place; be transported halfway across the planet in seconds; and be stolen without your knowledge. ”— Bruce Schneier


Hoping your users will report crashes

What do most people do when they see an app crash? They either try again or just hit the Uninstall button. Well, there are some “angel” users who actually go through the pain of reporting the crash to us, but that’s a very very small group of people.

Since Android is a vast ecosystem, and almost every manufacturer modifies the OS to their own requirements, it’s most likely that your app might suffer crashes on a variety of devices. However, since most users choose not to report the crashes, you are never notified of the same.

So, instead of relying on users to report crashes, apply your own automatic crash reporting mechanism. Attach Crashlytics from Twitter’s Fabric (now acquired by Google) suite to your project and you’re done. Every crash from now on will get automatically reported without user intervention.

“Defect-free software does not exist. ”— Wietse Venema


Not being friends with the IDE

Your IDE is the place where you spend most of your time developing your app, so treat it like your best friend and get to know it better.

Learn various shortcuts that you can use to navigate smoothly and swiftly across your codebase and also to help you write code faster with less effort. Here’s another short list of most used keyboard shortcuts.

This might take some time to get used to, but once you’re comfortable this can save you a lot of time and effort both while writing your app as well as debugging it.

“We shape our tools and afterwards our tools shape us. ”— Marshall McLuhan


That’s all for now folks. Cheers to being a better Android app developer!

Submit a comment