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.
Challenges
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 buildmobile.com.
Bruce CooperBruce 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.
