Developer blunders, Android edition: How to avoid 5 common mistakes

Google’s hands-off, democratic vision of mobile application development is both a blessing and curse for developers. While the open-source nature of Android serves as a low-barrier of entry, it also necessitates giving due diligence to every development quirk that could snowball into an underwhelming user experience.

Producing intuitive, beautiful and functional apps means anticipating the difficulties posed by the Android operating system—and planning around them before they lead to poor ratings and sadness all around.

After building more than 30 Android apps, I’ve seen a lot of bugs and errors. To save you the time and effort, I’m sharing five of the most common Android development blunders and what can be done to prevent them.

1. Looking like an iOS app

A lot of dev shop clients want to port existing iOS apps to the Android platform and recycle the same design. That’s a horrible taboo to break. Android applications have their own look and feel that is distinct from iOS and other platforms. What makes sense on iOS doesn’t always make sense on Android. Plus, users are smart and will call out and give poor ratings to Android applications that look like iOS applications.

Google has written extensive Design Guidelines elaborating on how Android applications should look. Read it! Learn it! Some design rules are made to be broken and you can distinguish your application by bending the rules in shrewd ways—but you should learn the rules before you play ball.

2. Poor support for multiple device formats

Android device fragmentation is real. There are lots of versions of the operating system, lots of screen sizes, and lots of keyboard layouts in the ecosystem. Many applications do a poor job of supporting the vast diversity of devices in the world.

It doesn’t have to be so hard. Android gives developers an array of tools to combat this bewildering space. Here are some things to remember:

• Use dp (density-independent pixels) or layout_weights to layout your UI. Density-independent pixels are scaled automatically by the layout system to be approximately the same size regardless of screen size and density. layout_weights are useful if you want to device the screen into regions that are proportionally the same regardless of the screen size (e.g.: when you want the left pane to be one-third of the screen-width on all devices). Note that layout_weights force the layout routines to repeatedly measure your Views on screen and can be slow.
• Use XML resources as much as possible to layout your screens. You can provide alternate layouts for different screen sizes to be automatically used at run-time.
• Be careful if you decide to lock the screen orientation to portrait-only. Many Android devices with slide-out keyboards will switch to landscape orientation when the keyboard is pulled out. If your application is locked to a portrait screen-orientation then you may infuriate your users.

3. Loading too many big images

Handling large bitmap images on Android is hard. We still haven’t found the silver bullet that helps us load as many images as we want without running out of memory.

The main problem is that the amount of RAM available to individual processes in Android applications is disappointingly small. The maximum heap size keeps getting bigger and bigger with successive OS releases and fancier devices, but it’s hard to believe that we’ll ever have the luxury to load as many huge images as we could in desktop environments.

What can you do? First, make sure that you are not leaking references to your images when you’re done. You want to get that image off of your heap as soon as possible. And if you’re really serious about freeing up much needed RAM, here are some other things to consider:

• Make sure to set the callback on your Drawable objects to null when you’re done with them.
• Don’t leak references to Activities or Contexts that could reference your images, or any views that could reference your images.
• Don’t build full screens using images. Be clever and change your screen to use combinations of smaller images and XML-drawables, if possible.

4. No visual indication when touching buttons

This problem is simple to solve, but I’ve seen it done poorly so many times. Your application needs to give positive feedback when the user interacts with the application’s display. If you touch a button, it should be highlighted.

Android makes it easy to provide different graphical states for on-screen elements based on their current selection or pressed states. You need to assign a StateListDrawable to your custom screen elements. The easiest way to do this is to create a drawable XML file with a state selector (see the above link for an example).

5. Blocking requests on the UI-thread

Have you ever seen an application hang and stop responding to your input? Did you see the dreaded Application Not Responding dialog box? These little emergencies can occur if you block your application’s UI-thread for too long.

If anything running on that thread takes too long (for example, network or database requests) then the user can experience a jarring episode of jankiness. A lot of users can’t tell the difference between these kinds of hangs and mundane crashes and will think your application is buggy (which, for all intents and purposes, it is).

This sin is so grievous that applications targetting the Honeycomb API, or greater, will experience NetworkOnMainThreadException if the application makes a network request using the UI-thread.

How do you guard against these misdeeds? Use AsyncTasks and ThreadPoolExecutors to toss your blocking calls onto worker threads. When your background tasks complete you can use callbacks or post messages to your UI-thread’s message loop to process the results.

Overall, there are myriad challenges to overcome when designing Android apps. As a developer, working around these common blunders means you’ll have a better shot at creating smooth functionality and an elegant interface that will be critical for keeping your users happy.

Rob Szumlakowski is an engineer at Xtreme Labs with extensive experience in Android and iOS software development and has been involved with the creation of several popular Android applications, including Dictionary.com, Fandango, and the Globe and Mail. When not building amazing mobile apps, Szumlakowski is travelling (34 countries so far), cycling, snowboarding, practicing photography, or cooking up a storm.

Top image courtesy of ostill, Shutterstock