Top 10 Most Common 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 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.

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. Bu 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:

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);

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.

As you learn Android programming, you will come to know and fear this message. Follow these Android programming tips to minimize this occurrence.

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!

Common Mistake #7: Not Assuming Success

Great. We have learned that there is a better way for handling long running tasks, and we are using well documented libraries for that purpose. But the user will still have to wait. It’s inevitable. Packages are not sent, processed and received instantly. There is a round trip delay, there are network failures, packages get lost, and dreams get destroyed.

But all this is measurable. Successful network calls are far more likely than unsuccessful ones. So why wait for server response before handling the successful request? It’s infinitely better to assume success and handle failure. So, when a user likes a post the like count is immediately increased, and in unlikely event that the call failed, the user is notified.

In this modern world immediate feedback is expected. People don’t like to wait. Kids don’t want to sit in a classroom obtaining knowledge that has uncertain future payoff. Apps must accommodate to the user’s psychology.

Common Mistake #8: Not Understanding Bitmaps

Users love content! Especially when the content is well formatted and looks nice. Images, for instance, are extremely nice content, mainly due to their property of conveying a thousand words per image. They also consume a lot of memory. A lot of memory!

Before an image is displayed on the screen, it has to be loaded into the memory. Since bitmaps are the most common way to do this, we’re going to provide an Android programming guide for the whole process:

Let’s say you want to display an image on your screen that you just took with your camera. The total memory needed for this is calculated with the following formula:
memory_needed_in_bytes = 4 * image_width * image_height;

Why 4? Well, the most common / recommended bitmap configuration is ARGB_8888. That means that for each pixel we draw, we need to keep 8 bits (1 byte) for the alpha, the red, the greed and the blue channel in memory, in order to properly display it. There are alternatives, like the RGB_565 configuration that requires half the memory than ARGB_8888, but loses the transparency and the color precision (while maybe adding a green tint).

Let’s assume you have a brand new device with full HD screen and 12 MP camera. The picture you just took is 4000×3000 pixels large and the total memory needed to display it is:
4 bytes * 4000 * 3000 = 48 MB

48 megabytes of your RAM just for a single image!? That’s a lot!

Now let’s take the screen resolution into consideration. You are trying to show a 4000×3000 image on a screen that has 1920×1080 pixels, in worst case scenario (displaying the image full screen) you shouldn’t allocate more than 4 * 1920 * 1080 = 8.3 MB of memory.

Always follow the Android programming tips for displaying bitmaps efficiently:

  1. Measure the view you’re showing your images in.
  2. Scale / crop the large image accordingly.
  3. Show only what can be displayed.

Common Mistake #9: Using Deep View Hierarchy

Layouts have an XML presentation in Android. In order to draw content, the XML needs to be parsed, the screen needs to be measured, and all the elements need to be placed accordingly. It’s a resource- and time-consuming process that needs to be optimized.

This is how the ListView (and more recently the RecyclerView) works.

If a layout has been inflated once, the system reuses it. But still, inflating the layout must happen at some point.

Let’s say you want to make a 3×3 grid with images. One way of doing this is a vertical LinearLayout containing 3 LinearLayouts with equal weight, each of them containing 3 ImageViews with equal weight.

Some Android programming beginners don’t always make the best use of LinearLayouts.

What do we get with this approach? A warning that “nested weights are bad for performance”.

There is a saying in the Android programming world, that I just made up: “With little effort all hierarchy can be flattened”.

In this case RelativeLayout or GridLayout will efficiently replace the nested LinearLayouts.

Common Mistake #10: Not Setting the minSdkVersion to 14

Well, this is not a mistake, but it is bad practice.

Android 2.x was a huge 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.

The numbers are clear, the users have moved on, the developers shouldn’t stay behind.

I’m aware that this doesn’t apply for some big markets with old devices (ex. India), and setting the minSdkVersion to 14, on the Facebook App, means leaving couple of million users without their favorite social network. But, if you are starting fresh and trying to create a beautiful experience for your users, do consider eliminating the past. Users that don’t have the resources, or feel the need to upgrade their device/OS, won’t have the incentive to try out a superior version of your Android app and ultimately spend money on it.

Wrap Up

Android is a powerful platform that evolves quickly. It may not be reasonable to expect users to keep up the pace, but it’s crucial for the Android developers to do so.

Knowing that Android is not just on our phones or tablets is even more important. It’s on our wrists, in our living rooms, in our kitchens, and in our automobiles. Getting the basics right is of utmost importance before we start expanding.

Duplicated (with very slight modifications) and posted with consent of Toptal. Original written by Ivan Dimoski – Android Engineer @ Toptal and posted on (
#Android #Mistakes

Read More

Samsung SmartThings

Samsung SmartThingsI was recently lucky enough to be given the newly released UK version of the Samsung SmartThings home automation Starter Kit to try out.

Home Automation has long been the dream of geeks and the rich, but kits like this are doing a lot to put the technology in to the hands of your everyday person. At the £200 mark it’s not expensive and whilst the software is somewhat unintuitive at times, it’s a lot easier than many rival bits of kit at this price point.

I’ve long held an interest in home automation and have recently moved in to my own flat after a few years of renting, so I’m excited to get dug in. That said, Samsung have kitted out the hardware such that anything that needs to be attached to the wall comes with sticky pads as well as screws, so even if you don’t own the property you can still use everything in the box without your landlord/lady becoming irate.

The Samsung SmartThings kit is of particular interest to me as it’s a professional piece of kit but also open source and hackable. It supports ZWave and Zigbee protocols (among others) which cover a lot of the good hardware out of the market already, and a good deal of what’s coming out in the future. The development kit allows developers to do a load of neat things like integrate otherwise unsupported, third party hardware, to scripting interactions between connected devices. I haven’t had a chance to actually get down and dirty with the coding side of things, but I intend on jumping in to the web based IDE and active support community soon! More info over at

In terms of the kit you get in the box – the hub and additional hardware (presence sensor, motion sensor, multi-sensor and socket) come with batteries and instructions to get you going. Control of the kit is done exclusively through a mobile app.

A basic rundown of the way the app works is thus:

  • You can have multiple locations (home, office etc)
  • Each location can have multiple “Modes”. A “Mode” is similar to a state – you can be in multiple modes at once, for example “Home” and “Night”.
  • Each location can have multiple “Things” (hardware, ie multi-sensor) associated with it.
  • Each location can have multiple rooms (“Lounge”, “Kitchen” etc) which you can assign “Things” to. From what I can tell, rooms are just a grouping mechanism and don’t really server any other purpose.
  • Each location can also have multiple “SmartApps”, which are scripts that say “If X happens, do Y” – think
  • Each location also has a “Family” section which tells you if anyone with a presence device or smartphone running the SmartThings app is present or not.
  • You can define routines, which allow you to pre-define configurations of all your hardware and mode state. Routines can be triggered manually or automatically based on various criteria (time based, sensor status etc) and there are options to send various alerts when routines get automatically activated (push notification and text message). An example of a routine would be “If motion is detected and it’s night time and nobody is home, turn the socket on and send a text message”
  • There’s a notification panel which shows you all the things that have been going on with your automated home.
  • Lastly there’s a marketplace where you can get forwarded to placed which sell supported pieces of kit, or browse and install various scripts to add functionality to your kit. A script that I particularly like is the “Door Knocker” script which alerts you if it detects a knock on a door (using the multi-sensor) but doesn’t then detect you opening the door after a set period of time.

There’s a fair amount of functionality packed in to the app, which sometimes means hunting through menus to try and find the functionality you are looking for. Also, the app currently only allows one device to be connected to your hub, something which the developer team assure me they are hard at work trying to fix.

It’s still early days for SmartThings in the UK, but the list of supported devices is getting larger all the time. I’m voting with my wallet and have already purchased a couple more motion sensors and multi-sensors, and plan on using the supported Sonos integration to create an instant Party routine (lights low, music on high!). Now I just need to work out how to get a disco ball integrated in to the system – needless to say I’m confident there’s a way to do it.

Read More

Introducing Tab Queue in Firefox for Android

We’ve known for a long time that the average user attention span on mobile is incredibly short; the longer content takes to load, the higher the chance the user will give up. No wonder so much emphasis is placed on load times and the pursuit to get something in front of the user as fast of possible. It ridiculous to think that such great leaps have been made in the world of mobile computing but loading web content on mobile can still be a slow and frustrating experience.

Chris Lacy wrote about a few of the issues surrounding mobile web browsing when he announced Link Bubble in March 2014. Link Bubble loads web pages in the background, providing a minimal user interface to give progress feedback to the user and a way of viewing the content once it’s loaded. It’s a great concept: rather than attempting to fix slow load times; accept that mobile browsing can be slow and work around it. Chris didn’t improve browser performance or provide any page load optimisation but he managed to push mobile web browsing to a new level by removing the point of friction between the user and the inherent issues of the platform.

Inspired by Chris’ work, Anthony Lam and I started thinking about how we could apply a similar thought process to Firefox. In line with our other ongoing work around continuity, we wanted to give users a way of using Firefox which feels more natural and stops them having to work around limitations of the browser. We came up with the idea of a tab queue which will allow users to effortlessly queue up multiple sites of interest and open them at a later time.  

Tab queue notificationThe feature is currently available in our nightly builds for Android. It’s early days and there’s still work to be done before we remove the nightly flags, but we’d love to hear your thoughts, comments and suggestions. For more info check out Anthony’s post about Tab Queue which has more details of the implementation and UX considerations.  You can keep track of the work we’re doing of this front by visiting the Bugzilla page.

Read More

Registers in Vim

Registers in Vim let you run actions or commands on text stored within them. To access a register, you type “a before a command, where a is the name of a register. If you want to copy the current line into register k, you can type


Or you can append to a register by using a capital letter


You can then move through the document and paste it elsewhere using


To access all currently defined registers type


Read More

Bookmarks in Vim

More Vim fun! This time looking at bookmarks.

To create a bookmark, simply type ‘m‘ where is any lowercase character. You can then use a backtick (`) followed by the letter to take you to the bookmarked position, or a single quote (‘) followed by the letter to take you to the start of the bookmarked line.

To create a global bookmark, useful for when you have multiple files open, just change the letter to uppercase (for example: ‘mA’)

To see all of your bookmarks type ‘:marks’ and to see info about a bookmark type ‘:marks ‘.

And – it wouldn’t be vim without a few hidden goodies – you can replace the letter with a full-stop to jump to the last edit.

  • ma – Creates a bookmark called a
  • mA – Creates a global bookmark called A
  • `a – Jump to the exact location (line and column) of the bookmark a
  • ‘a – Jump to the beginning of the line of the bookmark a
  • :marks – Display all the bookmarks
  • :marks a – Display the details of the bookmark with name a
  • `. – Jump to the exact location (line and column) where the last change was performed
  • ‘. – Jump to the beginning of the line where the last change was performed

Read More

Substitution in Vim

I’m getting to grips with Vim now, using it almost on a daily basis for as a JavaScript editor at Mozilla. One thing that I figured out today was how to do optional text substitution on a range of lines.

Text substitution in Vim is pretty easy using the ‘:substitution’ command (shortened to ‘:s’). The command accepts regular expressions, but can easily do ‘normal’ text replacement. It’s formatted like this:


<RANGE> is the range of effect you want the command to have, <BEFORE> is the word you’re searching for, <AFTER> is the word you want it replaced with and <FLAGS> are various flags which affect how the command works.

Let’s first look at flags.

Given the sentence: “I love giant killer robots and giant monsters. Giant Robots are the best.”

A simple substitution looks like this ‘:s/giant/massive/’ and when executed will change the first instance of the word ‘giant’ with the word ‘massive’.

The first flag I want to introduce is ‘g’, which will tells the command to execute across the entire sentence, not just the first match. So ‘:s/giant/massive/g’ will change the sentence above to “I love massive killer robots and massive monsters. Giant Robots are the best.”. Notice how the ‘Giant’ hasn’t been replaced – that’s because as standard we match in a case sensitive manner.

The next flag is the ‘i’, which will change from case sensitive pattern matching, which is the default, to case insensitive. The command ‘:s/giant/massive/gi’ will change the sentence to “I love massive killer robots and massive monsters. massive Robots are the best.”

Adding the ‘c’ flag will prompt you to confirm each substitution.

The range is where it gets interesting, and if I’m correct I think these range specifications will work on lots of Vim commands.

To execute a command on a range of lines you can simply add the line numbers before the command to execute, with a comma between the two. so ‘:10,20s/giant/massive/g’ will execute that command on lines between 10 and 20.

Vim comes with various non-numeric markers which you can use for the range.For example ‘.’ which refers to the current line and ‘$’ which refers to the end of the file. These can be mixed and matched as you see fit, so to specify between line 20 and the end of the file, my range would be ’20,$’. Vim will automatically assume that if you miss out one of the range values, you mean the current line, ‘.’. So a range of ‘., $’, from the current line to the end of the file, is the same as ‘,$’.

You may see the % marker preceding a command, which is a Vim shortcut for ‘1,$’ – beginning to end, or the entire file. ‘:%s/giant/massive/g’ will substitute every instance of ‘giant’ for ‘massive’ across the file you’re looking at.

If you want to specify a number of lines from where you are, you can use the ‘+’ sign – so ‘.+15’ means for the next 15 lines. As above, the ‘.’ is assumed, so this can be shortened to just ‘+15’.

So with that all in mind, to substitute text from the current line for the next 15 lines, asking for confirmation, you’d want to write something like ‘:,+15s/giant/massive/gc’

As ever is a great place to look at for help

Read More

A parcel from StackExchange

I had a slightly unexpected parcel arrive today, I say slightly because I knew about it a while ago but had since forgotten. I thought I’d do a small unboxing set of pictures.

2013-07-23 12.05.30
The parcel itself

2013-07-23 12.05.53
On opening

2013-07-23 12.12.37
Goodies! A couple of stickers, a couple of pens and a tshirt.

2013-07-23 12.13.33
I’m honoured to get a letter from Joel

So – just want to say thank you to the StackExchange people, very nice to have received this gift from your guys. And thank you Joel Spolsky – you made my day (and my girlfriends – she squeed when she saw who the letter was from. really!)

Read More

Learning Vim – Part 3

Wow – it’s been a long time since my last post on my journey into the world of learning Vim. Since then I’ve started a new job at the wonderful Mozilla as a mobile software engineer and they have a really messed up complicated build system, so even though I’m working on an Android project, I haven’t got the pleasure of being able to use any of the IDEs that I’ve grown to love. The majority of people I’m working with use Emacs or Vi(m), so it’s been a pretty good chance for me to get my learn on!

The first thing I want to go over is tabs – if you’re going to use Vim to develop in then learning your way around the tab commands are essential.

First things first – to open several files from the command line in tabs:
vim -p file1 file2 file3

Next are a few commands to open files in tabs and switch tabs:

  • :tabe <filename> → open file in new tab
  • :tabp → switch to previous tab
  • :tabn → switch to next tab

That’s pretty good, but it makes it a bit of a job to navigate quickly, so below is how to setup a mapping so we can quickly access these keys. I’ve setup these up as two key mappings to reduce the chances of anything conflicting with the new setup. Open up the file ~/.vimrc and at the bottom paste these lines:

map <c-m><c-n> :tabp<CR>
map <c-m><c-p> :tabn<CR>

The <c-m> is the access modifier, it means press the ‘Ctrl’ and the ‘m’ key and yes the ‘m’ is for Martyn :). After that, with the ‘Ctrl’ key still held, press either ‘p’ or ‘n’ for previous and next tabs. The <CR> at the end is required to mark the end of that command.

Next up is better navigation:

  • w → go to start of next work
  • e → go to end of current/next word
  • b → go to start of current/previous word
  • b → go to start of current/previous word
  • 0 → go to start of the current line
  • ^ → go to start of the content in the current line
  • $ → go to the end of the current line

Sticking a number before each of these will repeat the command, so 2w will move you to the start of the next word twice, 2b will move you to the beginning of the previous word.

Searching is quite important, and fairly easy:

  • /<SEARCH TERM> → find the search term in the current file
  • n → after you have searched, this will go to the next occurrence

Search and replace is also essential and again pretty easy:

  • :s/SEARCH TERM/REPLACE TERM/ → replace the next occurrence of the SEARCH TERM in the current line with the REPLACE TERM
  • :s/SEARCH TERM/REPLACE TERM/g → replace every occurrence of the SEARCH TERM in the current line with the REPLACE TERM
  • :%s/SEARCH TERM/REPLACE TERM/g → replace every occurrence of the SEARCH TERM with the REPLACE TERM

Read More

Accepting incoming tcp ip connections in (K)ubuntu

I’ve recently spent a bit of time trying to work out why I could accept incoming connections on my Kubuntu laptop. Initially I tried to get Charles to work but couldn’t get it to see any traffic coming from my Android phone – I put it down as a bug in Charles and left it. Today I tried to get Synergy working and again nothing, which prompted me to investigate further. I know Synergy was working on my laptop as a client, but I was trying to make it a server today, and it wasn’t showing anything being able to connect. This sounded very much like I was behind a firewall – but to the best of my knowledge I don’t have a firewall on my laptop. Anyway, turns out the ports were closed and the following command allowed me to open them (24800 for Synergy, Charles works on port 8888):

sudo iptables -I INPUT -p tcp --dport 24800 -j ACCEPT

Read More