Smartphones

What I hate about developing for Android (and some workarounds that help)

The open-ended nature of Android development fosters great opportunities, but it also brings its share of headaches. Here are 10 problems you'll face -- and some ways to deal with them.

Developers across the mobile space struggle to produce intuitive, beautiful apps for the Android platform. Their challenges spring from the plethora of devices available on Google's operating system, as well as inconsistent operating system upgrades. Google's arguably too-democratic vision for mobile development can also be a source of problems. Here's a list of reasons why Android is often the bane of an app developer's existence. Of course, given Android's large and rapidly expanding customer base, figuring out how to develop a great app on Android is a must. Therefore, I also provide some effective workarounds for developers coping with the limitations of the Android platform.

Note: This post was first published in TechRepublic's 10 Things blog on August 10, 2011.

1: Software fragmentation

Simply put, there are too many versions of the Android operating system in circulation. This means that developers can't just focus on the most recent versions of the OS; not everyone has upgraded. It's not easy for users to upgrade their operating systems, and carriers have little incentive to do so. For example, we bought an Android phone in February 2011 that came equipped with Android 2.1. Version 2.2 had been released way back in July of 2010!

Workaround: Learn which operating systems are most popular and develop with the latest widely adopted version in mind. Get to know handsets that are popular among your customers and familiarize yourself with the carriers' upgrade schedules. Another alternative is the lowest common denominator approach: Don't make an app that won't work on the oldest OS that's still in wide circulation.

2: Hardware fragmentation

Developing for the iPhone is easy from the hardware perspective. There are currently only five devices running iOS. By contrast, there are at least 170 running Android, with widely varying features, from keyboards (or lack thereof) to cameras to buttons, plus different screen shapes and sizes. It's a development nightmare.

Workaround: Again, market research. Find out which handsets are most popular with your target audience and develop for those first. Expand from there if and when possible.

3: Lack of software/hardware integration

Button A on Handset 1 does Function X. The problem? Button A on Handset 2 does Function Y. Here's a look at the variety of button configurations. Whoa. So obviously, you can't design an app that relies on Button A to do the same thing for everyone. Users may grow frustrated and give up on an app that doesn't perform intuitively.

Workaround: Once you understand which phones your users prefer and how they use features like touchscreens and keyboards, you can start designing an app that (hopefully) operates intuitively for most of your users. Focus groups or crowdsourcing through social media are two good ways to gather this information, but you will also want to play around with many different Android handsets yourself to get a feel for the user experience.

4: Too many carriers making too many changes to the core OS

Unlike Apple, whose devices are available only on two carriers in the U.S., Android phones are carried by all U.S. cell phone companies. And while Apple is strict when it comes to controlling the features of its phones, Android's carriers have leeway to modify the OS for their purposes, adding, subtracting, and modifying features and libraries at will. This compounds fragmentation problems.

Workaround: Find out which carriers your users gravitate toward and work with their specifications first. At the moment, Verizon and Sprint have the lead, but be sure to keep an eye on the market and shift your development resources accordingly.

5: Google's lack of authority

Google has taken a deliberately hands-off stance when it comes to the Android OS. Open source code provides a low barrier to entry for app developers, which can be a blessing and a curse. A lot of developers (myself included) would like to see Google police the ecosystem better, implementing more rigorous standards and an app review process. If Android provided more universal UI guidelines (and components) like Apple's, we might see better apps as a result.

Workaround: The good news is that Google seems to be moving in the right direction with the upcoming OS update. It claims that the new version will make it easier to produce attractive, user-friendly apps for Android. We'll see.

6: Security issues

Lack of governance in the Android market has led to a proliferation of malware programs that can masquerade as trusted apps. The openness of Android has made it susceptible to attack. To make matters worse, unlike traditional open source software, fragmentation on Android makes it difficult to roll out fixes, so many devices remain vulnerable. It's hard to keep customers happy and retain trust when security problems can't be fixed quickly.

Workaround: Monitor your apps for security issues and stay tuned to the happenings in the platform. When security problems do arise, have a plan to ensure that your users understand the scope of the problem and the extent to which it affects your application.

7: Market research cost

As mentioned, understanding your customer is the key to getting an Android app right. This, of course, requires lots of research into how customers use the software and hardware on their phones. And, yes, that takes time and can therefore be an expensive endeavor for developers to undertake.

Workaround: If you're committed to developing on Android, just dig in. Google does provide some user statistics that can get you started. But the best thing you can do is to use focus groups and customer surveys to understand your user base's behaviors and then allocate development resources appropriately.

8: Patent issues

In light of the recent lawsuits, there is a possibility that certain Android features could be declared in violation of patent law. Manufacturers might also be forced to pay licensing fees. If this happens, it could have a huge impact on the Android platform. It's impossible to guess now how it will turn out, but this litigation is enough to make some people nervous about dedicating development manpower to Android.

Workaround: There's nothing to be done about this now, but mobile app companies would be wise to stay abreast of this litigation and make development decisions accordingly. Google seems to be taking a strong stance against the patent litigation, so there's good reason to believe they won't just roll over on the platform.

9: iPad domination

As of now, Apple's iPad has effectively cornered the market on tablets. That isn't to say that we never will see a strong competitor (or many), but it doesn't exist yet. For a lot of developers, it's just not worth developing for the Android tablet platform yet.

Workaround: For now, just keep an eye on the tablet market. When a strong alternative with a competitive price tag does find its way to market (and they're getting closer), you will want to be ready to develop on it. You should also consider rich, HTML5-based Web apps that work well on tablets until you can develop native apps for Android.

10: The Android Market search engine

The irony is painful. Google's Android marketplace just isn't very searchable. In some cases, even searching for an app by its exact title won't bring it up. There are a lot of apps in the marketplace, and it's hard to be sure yours will be found. The marketplace also doesn't have a recommendation function, forcing customers to choose between apps without any reliable method for separating the wheat from the chaff.

Workaround: The best thing you can do is to understand how the app marketplace works and use search engine optimization techniques that take this into account. For example, while the Apple store seems to favor titles when returning searches, the Android store favors app descriptions. It may also be worth looking into secondary app marketplaces like Evernote's Trunk. This can be a great way to drive potential customers to your app and to increase the likelihood of being found within the Android marketplace.

The upside

Of course, it's worth noting that there are some really cool aspects of developing for Android. The open source nature of the Google operating system means developers have a good amount of leeway, for better or worse. Creative developers with good ideas may find that they can pioneer more interesting apps than they could on the closed iOS. Google also doesn't police apps entering its marketplace, so getting in is as simple as submission. If you can develop an Android app that works intuitively, looks great, and can be found in the marketplace, you stand a strong chance of capitalizing on this strong and growing market.

Anand Rajaram is the cofounder and chief product officer for OfficeDrop, a digital filing cabinet with scan-to-cloud apps for Mac, PC, iPhone, iPad, and Android. Anand has extensive experience developing Web/mobile apps and playing Angry Birds. Shockingly, he prefers iOS.

About

Mary Weilage is a Senior Editor for CBS Interactive. She has worked for TechRepublic since 1999.

12 comments
rainymanyu
rainymanyu

I am so sorry that I didn't see ur bullshit "article" before.. Anyway I guess time showed u (and it will show you even more) that you was living in iSheepland.. All and repeating all of your point are nonsense, from fragmentation, with security, iPad domination (maybe in ur toilet), til trolling about patents problems. Please read your "article" again and be honest with your self. Cheers

Kyle.Miller
Kyle.Miller

Sure, there are more devices to support than iOS. However, if you have ever done web development I think you'll find styling a web site to be compatible with all browsers, screen sizes, and screen resolutions much more difficult. I have 9+ years experience of web development and nearly 2 years of Android development and I can definitively state that developing for Android is a walk in the park compared to web development.

techrepublic@
techrepublic@

I don't understand all this whining (yes, whining) about Android's fragmentation. Compared to iOS or Windows Phone, yes, Android is more fragmented but just think of Windows, GNU/Linux, or *BSD and see how good the Android developers have it. "Simply put, there are too many versions of the Android operating system in circulation. (...) By contrast, there are at least 170 running Android, with widely varying features, from keyboards (or lack thereof) to cameras to buttons, plus different screen shapes and sizes." I wonder how Windows+PC and GNU/Linux+PC developers manage with the millions of different hardware combinations, dozens of OS versions, multitude of screen sizes and resolutions, single and multi-monitor setups, mouse?, pad?, trackball?, joystick?, gamepad?, camera?, etc. "It's a development nightmare." Exaggerate much?! I have only been developing Android software for an year and only a hand full of apps (mobile versions of existing desktop applications or web services) while I have been developing desktop, server and web applications for more than a decade. Still, I find it significantly less challenging to support the few dozens of Android smartphones types my clients use than the hundreds of desktops my clients use.

spdragoo
spdragoo

It's a wonder that anyone's even bothering to develop for Android then. The closest I can imagine to that kind of spaghetti-shaped mess is if a programmer was somehow trying to develop different versions of apps that would run on Windows 3.1/DOS, Windows 95/98, Windows NT *and* Windows XP...while also trying to transit to a 64-bit version.

.Martin.
.Martin.

I wasn't aware that you could get different shaped screen. I had thought they were all rectangular....

NickNielsen
NickNielsen

Your post has been flagged as offensive. Not because the post is incoherent. Not because you woke a zombie discussion. Not because you're a troll. The post was flagged because it didn't make us smile.

spdragoo
spdragoo

With Windows & Linux, you don't have to worry about a different version of the OS treating your Enter/Alt/CTRL keys on your keyboard differently [which is the example listed in the article]. Sure, there are various types of keyboards out there that add different functionality beyond the base 101/102-key IBM standard...but they do it by adding additional function keys to the keyboard that interface with the appropriate driver, not by removing/replacing the functionality of *standard* keys. Same happens with monitors, display sizes, etc.: base functions are already controlled by the default drivers, with any additional functionality (i.e. multiple monitors, available display sizes) handled by the hardware vendor's physical hardware & their 3rd-party driver files.

techrepublic@
techrepublic@

or you would not have written such nonsense!

techrepublic@
techrepublic@

"With Windows & Linux, you don't have to worry about a different version of the OS treating your Enter/Alt/CTRL keys on your keyboard differently [which is the example listed in the article]." It seems you did not understood what the article was referring to. The example in the article was *not* about "Enter/Alt/CTRL keys" or other *standard* keys (e.g. alphanumeric) but about the physical buttons on the phone. Those buttons are usually used by the system for system wide functions, are *not* standard keys (may not even exist) and should not be required by user level applications. A applications should never assume a particular "screen size and resolution". Doing otherwise is very poor programming. This is true for Android, iOS (e.g. iPhone and iPad), Windows, GNU/Linux, FreeBSD, etc. Also there is no way that a hardware driver can automagically make a application designed for a fixed screen size and resolution look good on a very different screen size and resolution. This is something that the applications itself has to do. Same for other hardware differences. Cameras for example. An application should not expect the system to have *one* camera. It may not have a camera or it may have more than one, and with varying resolutions and capabilities.

spdragoo
spdragoo

So you're denying the blog author's claims that the differences between the different versions of Android OS make it more difficult to develop an app? I may not have programmed for Android, but I compared the author's claim to trying to develop a program simultaneously for the various 16-/32-/64-bit flavors of Windows, something which I *am* familiar with. Now, since you didn't provide any examples to counter the author's article, we can only assume that *you* don't know anything about programming at all, let alone for Android.

techrepublic@
techrepublic@

"So you're denying the blog author's claims that the differences between the different versions of Android OS make it more difficult to develop an app?" No, I'm not denying that it is more difficult. I'm denying that t is a "nightmare" as the article states! "I may not have programmed for Android, but I compared the author's claim to trying to develop a program simultaneously for the various 16-/32-/64-bit flavors of Windows, something which I *am* familiar with." And it is a completely incorrect comparison, thus the nonsense part. "Now, since you didn't provide any examples to counter the author's article, we can only assume that *you* don't know anything about programming at all, let alone for Android." I did provide examples to counter the author's article. See my other posts in this debate.

Editor's Picks