What it’s like to be a 3rd party Google Voice Developer

I love Google Voice. I developed Think Messenger not because I wanted to make money or market to a large group, but because I wanted to use it. In fact, I used it for months before Apple approved it for the App Store. However, developing an application for the service, has been interesting to say the least.

Apps, whether they are first party or third, have to use an API to connect to any online service. Twitter for example has a very good public API, which has caused many developers to write apps to use the service. This breaks down to a set of URLs for getting information and performing actions on the server.

Google Voice has no public API. None. Other Google Services do, like Gmail or Google Reader, but Google Voice has yet to officially support any third party software of any kind. Pretty shocking when you consider how many tools there are.

So how do all of these apps interact with the Google Voice server? Well while there may be no public API, the Google Voice website still has to connect to the server with a private API. Basically all the Google Voice apps except for Google’s own, use the Google Voice website in the background and show a clean interface to the user up front. That is trickier to do than it may sound.

The first step is to figure out how the website talks to the server. This takes some clever reverse engineering. I personally used Safari’s excellent web developer tools to monitor requests made. That looked like me pressing a button, looking at what got sent to the server when I did that, and then trying to reproduce that result.

This causes a lot of problems because while I may be able to get it to work, there are still a lot of things about the API that I just do not understand, especially when it comes to the authentication process (logging in). It was that reason that made me switch to using a web login a la OAuth in 1.2. The number one complaint for the app is login problems, probably caused by something I don’t understand or missed about the API.

However, even once I had figured out how to connect to the server, there was still a very big problem, one that to some extent does not have a fix. That is, the API that the website uses is only used by the website, and was only meant to be used by the website. So you are limited to what the website does.

There are 2 different websites for Google Voice (well 3, but the old mobile version is useless for third parties), the desktop version and the mobile version. Think Messenger used the desktop version prior to 1.2, and the mobile version from that point on. Both have limitations.

The desktop version serves the data in a very odd fashion. It’s HTML fragments in JSON inside of XML. Christopher Nolan would be proud. I on the other hand couldn’t be more frustrated. Parsing XML and JSON isn’t too bad, but pulling data out of HTML is messy. There is a lot of extra parts to it for layout, and it can change with little notice. What’s more, that is 3 different parts I have to parse, which means 3 different libraries my code has to link to and 3 different libraries I have to learn how to use. And on top of all that, it takes forever to parse. The time it takes to load is 80% parsing on the phone and only 20% download time. I had to use multithreading to keep the interface responsive (which on a brighter note, makes Think Messenger ready to take advantage of the iPad 2′s dual core processor). It also lacks certain data; individual times for each message are not in a readable format.

So why would Google use such a cumbersome interface to their server? Because for what they are using it for, it is actually faster. The website doesn’t have to convert data into a view, it just puts the response from the server right on the page. The people who designed it never planned on any other use for it.

The mobile API is a lot nicer to work with. It returns data in a well formatted JSON document. When I switched to using it in 1.2, I was able to remove hundreds if not thousands of lines of code. And less code means less bugs.

But the mobile API has problems of it’s own. For instance, when you do an action, like archiving a conversation or sending a message, it doesn’t send you back the results of what you have done. You can see this on the mobile website. If you send a reply you have to hit refresh to see the message. The fix is to refresh after everything that could make a change, causing an increase in data usage and battery consumption (it’s still quit minimal compared to something like watching a video).

Another limitation that was easy to overcome is that the mobile website won’t let you send a message to multiple recipients. The fix? Send to each recipient individually. Rather than tell the server to send to John, Frank and Matt, you tell the server to send to John, then send it to Frank, then send it to Matt. Again extra data usage but fixable.

One problem that I have yet to overcome is that the mobile website does not really support replies. If you hit the text button on a conversation, you open the new message interface with the person’s info filled in the to field. What this means is that occasionally when you send a reply in the app, it won’t show up. Instead it will be added to the most recent conversation with that person or to a new conversation. I have already had several complaints from beta testers that they thought that the message didn’t get sent. Again, there isn’t much I can do without official support from Google.

Then there are the feature requests I get that I have no control over. Things like people wanting messages grouped by sender rather than conversation. I actually agree with this one, but it would not be very wise to go against the core of how Google Voice works.

Another common request is support for sending pictures. Google Voice does not support this at all. If you try to send a picture to a Google Voice number, it will tell you that it sent just fine, but the recipient will never have any indication that someone even tried to send them anything. Likewise there just isn’t any way to send a picture to someone. However, Sean Kovacs of GV Mobile+ did find a workaround similar to Twitter by uploading the image to a photo sharing site and including the link in the message. Admittedly, it’s something I never thought of doing. It still has it’s downsides, like only being viewable by people with smart phones, and you still can’t receive regular MMS, but it is a good example of how developers have to think outside of the box to make a good Google Voice app.

Push notifications are another beast entirely. Most service providers don’t provide support for notifications anyway. The only two examples I can think of are Facebook and Twitter. But Google Voice ads the additional caveat that you don’t have official access to your users accounts. I will write more about Push Notifications at another time.

With all the problems though, it has been a rewarding experience. I have also had to reverse engineer for iPhone Video Screen Capture. You tend to learn a lot when you look deep into the workings of a professional product.

Filed under: Programming Tags: App Store, Google Voice, Think Messenger for Google Voice