Do it on the device, or do it on the server?

This weekend, I thought I'd extend my little Android usage tracking application to work on more ISPs than the one (Internode) that it already does. As my phone is (sadly) on Optus, I thought I'd write one for that.

Internode was easy to add, as they have a documented API for accessing usage counters which are ideal for computer consumption. Optus on the other hand only provide a web application interface to check usage, necessitating the use of a web scraper. A web scraper is an application that pretends to be a user on a web page, makes all the appropriate calls (and fudges any javascript calls that are necessary) to get the results it needs. It then parses the (often non-compliant) HTML results that come back to get data. I have no problem doing this, and have done so on several occasions before, but it is not easy work and can be quite fiddly.  Parsing the HTML is often the most difficult part, as it is usually not well formed XML so you can't just use DOM to parse it.

In short order, I had a working prototype that used JTidy to clean up the HTML into something that I could use properly and then XPath to extract the elements of the document I needed.  It works great, except that the document clean up and parsing into DOM takes a really long time on a resource constrained device such as a phone.  It takes about 20 seconds to clean up and parse the document on my development emulator, which is too slow to produce a good mobile experience, especially if you have to parse multiple documents as I do.

So now I'm faced with a choice.  I could write a man in the middle service that the phone sends the user's login details to which then performs the parsing on behalf of the user and sends the results on to the phone, but there are a number of drawbacks to this:

1. This means that the user is sending his login details to a 3rd party, which is a security no no.
2. It introduces a single point of failure into the equation.  If my app gets popular the middle man service could get slammed.  If Optus decides that they don't like what I'm doing, they could easily block it.
3. It means I need to host a service, which means additional expense.

I don't want to do this, so what I'm left with is more hacky solutions, using regular expressions to find what I want in the HTML documents retrieved from the provider.  This will take me longer to code, will be more prone to failure, and is just generally nasty.  I'm not happy.  Devices these days are very powerful, and there should not be the need for intermediary servers to help with processing.

Of course this would all be much easier if the providers published web services interfaces to their data, rather than just web applications.  This has been the mantra of SOA and internet connected businesses since the terms were coined.  It doesn't even cost them that much more to do it, and would lead to better designed web applications, but thats a subject for another rant.  Optus doesn't do this because there's no economic incentive for them to do so.  They gain nothing directly from publishing a usable web interface, so they can't be bothered... bah!

To be fair to Optus, they aren't the only ones that don't get it.  No ISPs and telcos provide any decent interfaces, other than Internode.

I wrote an android application

I purchased an Android phone a few weeks ago. Part of the reason that I got it was that I wanted to see what the differences were between Android and iPhone.  This extends out to how to program them as well, so I had to write an application, just like I did for iPhone.

Last night, I released my little application.  Its a usage meter for my ISP, Internode. I deliberately chose something quite simple so that I could cut my teeth on the platform, and I must say that I'm very impressed. I found it very easy to write the application for Android, especially because it uses the same tools and libraries that I am used to using for my day job.  One other difference that I notice is that it is much more obvious what is going on inside an Android application.  The documentation describes things clearly and gives you full visibility.  Apple on the other hand like to keep their platform a little more mysterious.  There are plenty of good documents on how to do things, but you still get the impression that there's something going on under the hood that you don't quite understand.  Perhaps its just that I'm more familiar with the Java ecosystem.

If you'd like to have a look at it, check out its site at 8-bit cloud.  I've also been playing with the web site, and I will be improving it and hopefully making it more fun.

PS: I was tempted to call the application NodePony after a recent meme that Internode has got going with its cute little plush toys.  In the end, I decided that I shouldn't try to cash in on it.  It would spoil the meme...