Some Notes on Implementing In-App Billing on Android

About a year ago, I implemented in-app payments for iOS, and it was painful. Technically, it wasn't too hard but there were a number of hoops to jump though to get everything working. Lack of clear documentation and undocumented error responses seemed to be the primary problem - I think a hold up with verifying tax information on the developer account resulted in strange, undocumented failure codes in my case. There were several dozen blog posts complaining about many such "magic" issues back then. It was almost comical, to be honest.

This last weekend, I decided to add in-app billing to an app that's already shipping for Android, and I ran into a couple of hiccups that I think are worth documenting here to save others some time/pain. Overall, I think the Android folks learnt from some of the pitfalls that early developers hit with in-app payments on iOS and worked to fix those. The documentation is a lot clearer and precise compared to where iOS was a year ago. Android Market also has a nifty static test/response facility which makes it easy to test code without worrying about external influences. iOS was desperately lacking something of this sort (not sure if it's better now) - I even wrote a dummy implementation of the iOS in-app payment API and the different response conditions to let me test my code in an emulator, which was really helpful. I'm glad Android got this right (still no testing in an emulator though, which is a bummer because of the inability to test with different Android OS versions).

At a high level, the in-app billing protocol on Android is extremely chatty (see the diagrams on this page). It seems particularly so when compared to PayPal's rival offering. PayPal's in-app billing module handles payment using startActivityForResult and onActivityResult methods which can be used for communicating between child/parent activities. This is very similar to how Facebook's Android SDK handles single sign on. That model is extremely simple to understand and implement for developers - you could probably have it coded up and tested faster than you can finish reading this blog post. I think part of this chattiness is to ensure a higher level of security and also to handle managed purchases, which are both likely harder to do using PayPal's approach. I assume they had good reason to make it as chatty as it is now, but my gut says that Google loses out on a lot of developers because of this apparent complexity. Having said that, the sample application Google provides does a really good job of illustrating the various communications that need to occur, so studying that code makes the chattiness easier to understand (for some reason, code registers more easily in my brain than verbose documentation - good code and good documentation together are very rare, and Android seems to have gotten this right - kudos!)

One of the biggest red flags with using Android's in-app billing, however, is the development teams non-responsiveness to critical bugs. This issue, marked critical and accepted, talks about transactions failing 4-6% of the time, and has been active for over two months without an owner being assigned. An equally disturbing issue with unacceptably long latency when handling authorization has been open for almost two months without any comment from Google or even an owner being assigned. In fact, browsing the issues list certainly doesn't inspire confidence in the platform. It would be a big mistake by Google to not take these issues seriously. In my case, I'm certainly debating the merit of jumping into this as an early adopter.

Some other notes about implementing in-app billing on Android:

• It sounds obvious in hindsight, but you need to make sure that your application is signed with the release key before testing in-app billing, even the static response stuff. Developer's aren't used to doing this while debugging, so it's worth calling out in the documentation.

• If you want valid signatures for the JSON responses as suggested by the table here, the "debuggable" attribute in the app manifest should be set to false, even if you're using a release-key-signed APK and static responses. I was a little annoyed by this un-documented restriction because it basically meant that I had to resort to using logging as the only real means of debugging my code. If there is indeed some way to debug this using a debugger (and yet receive valid signatures), it’s definitely not obvious to me. Again, not a terribly big deal once you realize that this attribute actually seems to affect signatures, but that isn't documented anywhere.

• If you're using a server to validate signatures (as you should), be aware that the public key you obtain from the Android Market profile page is a base-64 encoded string. You will almost certainly need to convert it to PEM/DER format or use the x509 certificate for it to be usable with most server openssl implementations. For instance, this command can be used to convert the base-64 encoded key into a key usable by PHP:

  openssl enc -base64 -d -in publickey.base64 -A | openssl rsa -inform DER -pubin > publickey.pem

  Also, if you're using the PHP function openssl_verify, remember that $signature needs to be the binary signature, not the base-64 encoded signature string that the Android Market app sends (I found out the long way).

• Unavailability of subscriptions/auto-billing is a big gap in the offering currently, but I assume support for it is coming soon, since iOS already supports it.

• I hit an issue when testing payments using carrier billing, where accepting the carrier ToS basically causes the transaction to get lost somewhere between the carrier and Android Market. I logged this bug to track the issue.

Well, I hope that the web-search spiders do their job and this post helps others out there looking at implementing in-app billing on Android. And making Google get a move on those bugs.

Discuss this post on Hacker News

Google Instant's biggest win? Teaching users to search better

The biggest impact of Google Instant is that it teaches users how to search more effectively. Based on these dynamic results, users can tweak their query such that it helps them find the exact answer they were looking for, even if they started with a bad query. Teaching users how to improve their search query is huge. The immediate impact is that it improves users' perception of Google's search results. Same with speed - users will perceive Google as being much faster than anything else out there because of the instant results.

Perception is reality. Speed and relevance are a search engines bread & butter. I think Google just upped the ante by a lot.

Credit to Microsoft though - this probably wouldn't have happened if it weren't for Bing's recent gains. Proof that competition provides the best kick-in-the-pants needed to innovate.

Hey Google Buzz, I don't email my friends anymore

I just saw the presentation from Google about Google Buzz. The quick summary of the announcements - creating a social network using my email contacts and emailing history as the source of my social graph, and using rich geo-tagged status messages (buzz-es) to keep it updated. It comes with rich mobile apps to help this take off. They also promised enterprise versions of Buzz.

Buzz sounds pretty exciting. Some of the geo-tagged updates sounds really slick. My first reaction - this is going to be 'public follow' thing more than a 'follow my friends' things. Because emailing my friends is like, so 2007!

Fact is, I don't email my closest friends/family anymore. I either IM them, post on their Facebook page, send them SMS or call them. Email is more for work type, non-personal stuff. Having said that, it's important to note that Google does have GTalk and Google Voice so I hope they weigh activity from GTalk and Google Voice higher than GMail activity when figuring out who I must 'auto-follow'.

Time for someone to write a Buzz-to-Facebook cross poster. :)

More Food For Thought About Google And Exit Polls

A couple of months ago I conjectured that Google might be able to produce a very accurate exit poll for the '08 Election. Today's post on the Official Google Blog shows some information that's very close to what I suspected they could generate - very cool. Particularly interesting is analysis of traffic from swing states. I'm sure they could do much more here - trending by counties, for instance.

In that previous post of mine, I guessed that they won't publicly release a prediction, but bits and pieces of information and trends like these are a good stand-in for a full blown exit poll.

Surprised by Live Search

I use Live Search as my web search engine of choice, but every so often I need to use Google to find the information I'm really looking for. I was really looking for a site that gave me good side-by-side results from both engines - kind of like how dogpile.com used to work in the old days (I was surprised to find dogpile.com still alive and doing search compilation, but I really wanted a side-by-side view from only my two preferred engines).

Recently, as part of an internal Microsoft initiative, I found exactly what I was looking for - a site that runs the searches in parallel and presents them side-by-side. As a bonus, you get to vote on which engine performed better. I've been using this as my default search engine on all my machines for the last few days and I'm already pretty surprised at how often Live Search comes up with far superior answers. I guess I never paid to attention to comparative relevance and quality until it was presented to me in such an 'in-your-face' manner. Of course, there are still many searches where Google trumps Live Search. Anecdotally, I'd say I prefer Live Search about 60-70% of the time, but maybe that's just me (and it could well be my inherent bias for Microsoft products).

One aspect that simply blew me away was Live Search's ability to fetch answers for very specific things I was looking for. A lot of these are powered by something Live Search calls 'Instant Answers'. A few samples from queries I performed over the last week where I was really impressed by Live Search:

- MSFT GOOG AMZN AAPL quote vs MSFT GOOG AMZN AAPL
- seahawks schedule vs seahawks schedule
- highest peak in the US vs highest peak in the US
- calories in beer vs calories in beer
- president of somalia vs president of somalia
- Colt McCoy vs Colt McCoy

These were just some of the searches I ran last week - the Instant Answers site has other query formats you can try (incidentally, I didn't know about Instant Answers or the formats until just two days ago). One place where Google still beats Live Search hands down is showing inline maps and directions. I use this fact to give a lot of sh*t to a friend of mine who works on Live Maps - maybe one of these days I'll annoy him enough to make him go fix this stuff! ;)

Can Google Predict Election '08 Results?

Today's post on TechCrunch about possibly predicting election results using web traffic analysis reminded me of my thoughts from a few months ago.

Over the course of election season, starting with the presidential primaries through Super Tuesday and going into the national conventions, Google began releasing increasing amounts of election-related content and services. Reading the blog posts linked above and noticing the trend from Google leads to me the conclusion that the most relevant exit-poll for November's presidential election this year might actually come from Google.

Google likely already tracks user searches and email data from GMail. Combine that with some pretty basic data mining around traffic analysis, comments on their targetted election sites and popularity of their election related content/services and you could now get a pretty good 'pulse-of-the-nation' with respect to red state-vs-blue state. My guess is that the big push around election related content and services is an attempt to not only increase pageviews, but also harness large amounts of interesting data that can be mined for various interesting purposes. Additionally, this gives them a large data set to use to refine their own data mining technologies. I strongly suspect that Google will hold on to the raw data past election time and used it as test-data to track progresses in their mining technologies. Good data to test your technologies is *very* hard to to come by, and it would be foolish to let such rich data simply fall by the wayside.

Whether they publicly release their 'exit-poll' is another story altogether. I don't think Google really has much to gain by releasing the data even if they do manage to mine it. I know I wouldn't - I would mine the data, distribute predictions among team members for entertainment purposes only, see how close I got to the result, refine my algorithms and run it over the same data again to see how much closer I am now, and repeat. Releasing the data publicly, even if it turned out to be dead-on accurate, wouldn't buy me much. If it wasn't dead-on accurate, there is some amount of geek-cred that would be lost.

I guess November will prove if my theory above is correct.

P.S. I hope you picked up on the paradox in that last sentence above... :)

What Live Messenger, AIM and Y! Messenger Need to Remain Popular

Two things - broadcasting and aggregation.

Windows Live Messenger, AOL Instant Messenger, Y! Messenger and Google Talk and several others are hugely popular Instant Messaging applications. Almost all offer rich client experiences as well as web-based versions. I remember reading somehwere that IM apps are the most used apps on computers, and I am pretty sure they will continue to be for the near future. Demand for IM applications on the web is pretty strong too, with sites such as Meebo growing in popularity.

IM clients have been very innovative over the years, starting from simple 2-person chat to having multi-party conversations, voice support, application sharing, file transfers, etc. Innovation in this space seems to be slowing down though - I haven't seen any new game changing features in any of these IM applications. They all seem to have missed the move to a more social web. In many ways, these apps should have been the ones driving the social web, with their knowledge of social networks via friend-lists. However, websites like Facebook, MySpace and Orkut have firmly established themselves as the drivers of innovation in the social space.

Consumer interactions are evolving from being specifically directed to an individual or small group to being widely broadcast. Blogs, tweets and public profiles are visible to anyone and often are used as a broadcast medium. Increasingly, status messages on social websites and, more importantly, micro-blogging are encroaching on the IM space. Twitter clients such as Twhirl are a great example of this encroachment - users interact with it if it was an IM client but it's really just an app that allows broadcasting messages. YouTube is another hugely successful broadcast medium.

Ofcourse, users also want the ability to have personal, directed conversations along with the ability to broadcast - both to a select group (their network) as well as broadly to the world. For IM application to remain relevant and to fulfill this need, they need to include broadcasting features in addition to preserving the existing communication & collaboration experiences. There are multiple potential approaches to do this - use existing APIs of popular social platforms to allow users to broadcast to a specific network or to farm out to multiple social networks

With the desire to broadcast comes the desire to learn about what others are boadcasting. Most (all?) social websites have news feeds and services can aggregate several such feeds to present a unified view of a users online broadcasts/activity like how FriendFeed does. An IM application would be an ideal home for such an aggregated feed.

In many ways, Facebook is almost there with regards to being an ideal IM application. It has the advantage of being a really popular social platform, which certainly helps. Facebook recently complemented their broadcast communication feature (status messages) with IM-like functionality to enable personal communications. And of course, Facebook pioneered the news feed. Now if only they could go broadcast to and aggregate from competitor sites too... ;)

The arguments above apply even to corporate IM applications - this is not just a consumer need.
Unless traditional IM applications evolve to fill this need and compete with the Facebooks of the world, I see them dying a long, slow death.