By Bruce Cooper

Going Undercover on Android Apps

By Bruce Cooper

Bruce Cooper is an IT consultant who feels that in order to be able to serve his customers well he should have an understanding of the different technologies that are out there, and how they work. The best way to learn is through doing, so he often takes on small side projects to pick up a new technology. This article showcases one of his projects, a usage tracking application for Android called NodeDroid.

Profiling Android

About a year ago, a new generation of Android phones became available, and the buzz was that Android could now compete with iOS for features and desirability. I had already done some iPhone coding, plus I was in the market for a new phone, so I thought it would be a good opportunity to learn a new technology and hopefully produce something useful while I was at it.

Quick & Painless

When I was deciding what sort of app to write, I wanted it to be something simple, for a couple of reasons. Firstly, I wanted to learn the API and not over-tax myself. Secondly, by making it simple, I’d be more likely to finish up quickly and get it out to the public.

Publishing my app was important as I wanted to compare the experience of developing on Android to that of iOS. We’ve all heard the stories about having to deal with Apple’s mysterious approval process, and Google’s was supposed to be much easier. So off I went to the local phone store and I came back with a shiny new Samsung Galaxy S i9000.

One other thing I wanted to try out was mobile advertising. Again, we’ve all heard about people being able to make more money through in app advertising than through revenue from store sales. I didn’t expect much, but the only way to understand something is to do it. For advertising, I chose AdMob, as it appeared to be the preeminent platform at the time.

Taking Aim

I wanted to write something that would be useful for my target audience: me. I settled on writing a usage checking application, that would show the bandwidth usage of my phone (Optus) and my home ISP (Internode) to ensure that I didn’t go over my quotas. It would be called NodeDroid. Most of the existing usage checking apps for Android are either very basic or only work for one provider, and its information that I look up all the time. More information can be found about NodeDroid at 8bitcloud

After reading up on the technical details of how to program for Android, I started thinking about how the application should flow, and this is where I noticed the first differences between iOS and Android. Apple has gone to great lengths to specify the way that you will interact with iOS and the UI guidelines. The graphical interface builder goes a long way towards helping developers produce layouts that look like Apple UIs.

Whilst Android also has UI guidelines, they are less rigorously enforced. The GUI builder built into Eclipse for Android is terrible, meaning most people will end up building their interfaces by hand in XML rather than using a GUI builder, which often leads to ugly interfaces (As an aside, I think that programmatically built layouts can often work better than GUI built ones, but you need to put more effort in to get them right).

Other people have noted that the Android experience isn’t as consistent as iOS, and in my opinion this is one of the reasons why. I still wanted a good experience though, so a lot of effort was spent on making swipe gestures work correctly, including animation between states. I was a bit disappointed that it didn’t work out of the box. Some of this required specialised coding, which I will cover in another post.

Anatomy of a Mobile App

It is important to keep apps simple. Whilst it is tempting to put a whole bunch of stuff into an app, for mobile devices the limitations of screen real estate and input mechanisms mean that often, less is more. I didn’t want lots of buttons on my app; buttons, in general are a no-no on mobile apps, with gestures being a better way to interact.

Colour is also an important tool that allows you to differentiate between different components. NodeDroid supports accounts from multiple suppliers, with each provider displayed on a separate page. Colouring the pages with the colours of each provider means they become instantly identifiable by brand. Internode accounts ended up an orangey red, whilst Optus came out yellow. I’m no graphic artist, so the result was only partially successful, but I’m happy with the user experience that the colours provide. The effect would be even stronger with logos.

The last aspect of user experience I wanted to get right was how to show the results. The most easy to read format for info is graphs. I went looking for available plotting libraries, and found a few, but they were over complicated or too immature. In the end, as the graphs I was writing were very simple, I wrote my own components to draw the graphs.

Bringing it Together

So how did it end up? The first version of the application was quick to develop. This was aided by the use of Java as the programming language because I am a professional Java programmer, and switching to the Android APIs was easier than learning Objective-C for iOS. Working with Eclipse as a tool, in my opinion, is much easier than the awful XCode. Also, most Java APIs work very well on Android, meaning there’s lots out there already.

Publishing to the Android market was a breeze. After a one time US$25 registration fee (cheaper than Apple’s US$99 per year), I could publish my App immediately, through a straight forward web interface. This was especially useful when I found a bug in the first release, and needed to republish immediately to fix it. If I were dealing with Apple, there could have been a whole palaver about getting the new version out, but on Android it was simply a matter of uploading the new app bundle, and pressing Publish again. The market developer console also has a bunch of handy reporting tools which give you great feedback on downloads, issues, and comments.

Advertising was a mixed bag. Whilst installing and using adverts was easy, and I had a reasonable click through rate when adverts were available, often the service would be unable to provide adverts when requested leading to a poor number of ads shown (known as the fill rate). When this happened, it pretty much stopped the revenue dead. In the end, I made about $20 from advertising before I ended the experiment after two months. This sounds terrible, but remember this is a little app with only a few thousand users. It’s not going to pay the bills, but I can see why people like it as an approach: if you have a popular application with tens of thousands of users, advertising revenue could start to stack up.


One challenge that I thought was inevitable would be the sheer variety of different screen sizes and versions of Android that are out there, otherwise known as “fragmentation”. People have been making a big fuss over this, but I can’t say I’ve really had a problem. The Google tools allow you to target a specific version, and as long as you are willing to do without the latest APIs, you can target fairly old devices easily. I had to make a few adjustments, but it was easy to target all Android 1.6+ devices.

Screen resolution was a bit more tricky. You tend to write your application for one screen resolution, then see how well it works in others. Luckily Google has provided pretty good tools to make your UI scale well, and if you write your application correctly it should work smoothly. I won’t say that my application works perfectly on every screen, but it works well on the vast majority. In the end, fragmentation really hasn’t been that much of a problem for me.

The Future

There are a lot of improvements I could make to my little application. I want to add a home screen widget to it, plus it would be great to add additional network providers to it. I’m still trying to work out how to do this in a secure fashion so that collaborators don’t have to share passwords with me. Its hard to debug without an account to work with.

As a first step, I have open sourced the application, it is available at my GitHub NodeDroid repository. If you just want to try the application, you can get it from the Android Market. I’d also appreciate any feedback that you have for me on the application, or for any articles or techniques that you’d like to have written up on

  • Ian

    What made you decide to support Android 1.6+ devices and not any earlier or later?

    Look forward to reading more form you Bruce.

    • I had a look at statistics on handset ownership, and the versions that were out there. Virtually nobody used anything below 1.5 any more, so thats what I picked (Checking my code, I actually support 1.5+, not 1.6 as I said in the article. My bad!).

      I think its also a matter of understanding which API features you can’t do without. If I had needed server-push notifications or something like that, 2.0 would have been the minimum. As it was, the only real thing I had trouble with was detecting screen orientation. In 2.2 it is easier, but I managed to google a way of reliably detecting it for 1.5 so that was fine.

      Having a look at the stats for my app (, You’ll see the breakdown of users for my app, and also for everybody in the app store on the right. This bears out my assumption about versions. Less than 0.5% of all handsets out there run anything less than 1.5

  • You don’t have to forgo newer features in order to support older APIs. There are several ways of doing this that are documented on the official Android Developers’ blog.

    • Thats great Moandji, I didn’t know that. In my particular case, this wouldn’t help me though. I need a way to detect screen orientation which will work on every version I support, so I just had to come up with a way that would work for 1.5 as well as 2.3.

      If I was using, say C2DM, then selective support would be the way to go…

  • I am a professional programmer who works daily in Android Java, Objective C and .Net…handling screen size fragmentation and Orientation in Android is actually fairly easy and is analogous to designing websites or (more closely) working with XAML in WPF–or designing MXML interfaces in FLEX for an Adobe AIR Application. A lot of developers opt for creating a “lite” version of their apps for older platforms and/or smaller screens. (just watch as the wave of Android iTouch ripoff type devices comes–and, Yes I thing Samsung’s Touchwiz is grossly derivative and HTC Sense is not–Heck, Archos already sells several modern, small screen Android media players at your local Radio Shack/Best Buy/Sears/etc…)

    I kind of came at it from the other side–I was doing ActionScripting, Java and C#–and then learned Objective C and Cocoa. While the Apple IDE is truly first rate–dealing with the autorealease pool, allocation and overwritten references (memory leaks) trumps any complications in programming Android! I actually find Eclipse on the iMac to be much stronger/faster than the PC version (and I have never had to load a USB driver for any of our developer phones or even the Galaxy Tab), but Apache/Android/Java offers a host of language services that are wonderful (how about an Android Java calendar object that understands and handles Timezones, DST and Leap Years better than .Net does!)–I literally had to write over 3 times the amount of code to do the same thing in Objective C and that is a common occurrence for many, many common programming tasks.

    I know sometimes that is related to my lack of Objective C experience, but mostly it’s just the same ugly pointer/reference mess MS or Borland C++ gave you before .Net came out…And while I really like Coredata, using straight SQL on a Galaxy S crushed Coredata during my I/O performance testing for the “same” application on an iPhone 4–both use SQLite.

    But I have to say Coredata is even more elegant that Microsoft Entity Framework–and any Java entity framework for Android that I have found is “old dog slow!”

    Overall, I just expected the NS libraries to be a little more mature considering the long development history of the language. While Apple makes wonderful devices and some truly innovative software–I know I can produce stable, strong applications in Java and .Net in less time–and I feel this will still be the case after I gain better mastery of Objective C–just because it is C++. (the same is true of C++ on other platforms–with the possible exception of C++ .net–which is managed, and therefore “not really C++” ;-)

Get the latest in Mobile, once a week, for free.