The Problem

I jumped up and down with excitement when I received my Google Voice upgrade, for many reasons that excite me. First is being able to place calls through the number, and receive calls as well. Though, the most important was by far SMS. I do not have a messaging plan on my mobile because it is just plain expensive, but I do have a data plan on it: for work, for play, and because the price is certainly right.

The problem that I have with Google Voice at the moment, however, is that there are two ways to receive messages on my phone through my GV number:

1. Receive the message via SMS 

2. Check via www.google.com/voice/m/

Now, given what I have already said, the first option is out right away. So that leaves the option behind door number two – using my browser to check for new messages. Option two introduces an issue that, for me, defeats the whole purpose of SMS: notification.

My phone buzzes, dings, and changes the colours on my room’s walls whenever I receive a new email. (Okay, well, it does most of that). Sadly, it does not know when to set off its bells and whistles if the only way that it has to check for new messages is Pocket IE, Opera Mobile, or whichever other browser you prefer. This is an issue, since I don’t want to refresh the browser minutely, or even bi-minutely, to maintain a conversation with a friend.

Why not email their number?

Sure, you may point out that I can just email theirNumber@carrierSmsDomain.tld. I absolutely despise this method: it is tedious, prone to errors, and it means that I have to dig up all of these carrier emails, know if they change. Overall, it is simply a hassle, and hassles do not appeal to me.

Alright, alright. We get it - on with “The Solution”

The solution, in my humblest of opinions, is quite a simple one. Why not have Google Voice send new SMS messages to my email? It’s really quite an easy process, something that the “Big G” could implement with ease given they have direct access to the SMS receiving hooks. And yet, they have not. Not for a lack of request from their users, as numerous postings online show. Not from a lack of engineering and programming intelligence, as their Google Wave shows. Perhaps it is simply because the service is new and they do not want to overstuff it with potentially useless features. I truly do not know, I’d have to talk to Larry or Sergey to find out.

So, rather than waiting and speculating if the multicoloured giant will ever release this feature, I’ve decided to implement it myself.

How?

First I had to inspect the Google Voice system to see what potential methods were available for me to use.

The basic idea that I narrowed everything down with involves a lovely little friend of mine called Python, a module with the sweet name of “lxml,” and some inspection of the Google Voice system. At the time of this writing, I know what tactic I will be using because, well, I’ve already implemented it. The project is not released just yet because I’m still adding the gravy to my potatoes, but the core of my strategy has been prototyped, written, implemented, tested, and proven. The library uses a combination of Google’s mobile and “full” website, along with parsing the included JSON, in order to most efficiently and accurately retrieve new messages.

Password handling.

One obvious line of thinking is that I would have to store the passwords. This bothers me, since to make storing them useful I would either have to encrypt in such a way that decryption was swift (which would ultimately only be faux security at best), or I could store them plaintext.

“Which way, then?” you may be asking. My answer is quite simple: “Neither.” I do not like storing such sensitive data plaintext, and upon further inspection it is not necessary. When the library processes a login request it will store a persistent cookie to ensure that the session lasts for as long as possible. Of course, exceptions where the cookie expires or shows as invalid are handled appropriately.