The 5 Most Common Android Development Blunders

If you’ve developed an Android app before, then you’re probably aware of the difficulties that the Android operating system poses. For starters, Android has the most complex array of handsets, versions and carriers of any mobile platform. And if that wasn’t enough, unlike most closed operating systems, Android is an open-source platform which makes it extremely susceptible to malware. Trying to develop a secure but also feature rich app that maintains device consistency makes for a (very) big development headache. Developer Rob Szumlakowski of VentureBeat, who has built more than 30 Android apps himself, shares 5 of the most common Android development blunders and what can be done to avoid them. Here’s a look:

  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.

Keeping these best practices in mind can certainly better the outcome of your app. Though Android presents bigger challenges than other operating systems, Android will be around and widely used for quite sometime. Therefore, knowing the challenges and coming up with ways to work around them can help you address issues and launch better apps. To further assure quality, testing in-the-wild before launch is extremely useful for finding the real world bugs and glitches that didn’t occur during development or in the lab.

Looking for more resources on Android App success? Download this free whitepaper: 8 Tips for Android App Success

 

Essential Guide to Mobile App Testing

Comments

Leave a Reply

Your email address will not be published. Required fields are marked *