Background

In November 2010, Facebook announced that they’re enabling Single Sign On in the Android SDK. Applications that take advantage of this feature will allow users to skip re-entering credentials and dive right into the action. What they do not mention is that SSO isn’t a feature developers opt into, it’s actually on by default. However, it only changes the way the Facebook SDK works IF the Facebook application is also installed. This causes the problem that most developers (including myself) see when they first set out to build an application.

The issue

The typical description of the problem goes something like this: You’ve downloaded the SDK and your application is running perfectly with shiny new Facebook authentication on the Android emulator. But when you deploy it to a device, it no longer works. The app loads but the Facebook login dialog disappears instantly. If you’re more familiar with Android development than I was at the start, you start up your copy of adb logcat while your application is running and you see logs that look something like this:

D/Facebook-authorize( 2194): Login failed: invalid_key
W/System.err( 2194): com.facebook.android.FacebookError: invalid_key

At this point, you Google for solutions to the issue and quickly start pulling out your hair out at the number of people reporting this issue with no apparent fix. The problem is actually very simple, though not immediately obvious. The problem is that, when deploying your application to the device after developing on the emulator, you’ve inadvertently and implicitly enabled Single Sign On because your device has the Facebook application installed. This is why one of the reported fixes is to uninstall the Facebook application. Your emulator does not have the Facebook application installed (though the Facebook SDK includes it if you want to install it), but your device does, thus triggering the SSO code. And SSO has some special configuration requirements that non-SSO does not which causes the invalid_key error above.

Fixing the Issue

There are a few different ways to tackle this problem.

1. The ugly: Uninstall the Facebook app

Don’t do this. You’re not going to be able to ask your users to do the same anyway. The only reason this works is because the SSO functionality is triggered by the presence of the Facebook application and this simply removes the possibility of using SSO completely, which is also a crappy user experience.

2. The bad: Opt-out of Single Sign On

If you want, you can actually have your application skip SSO completely. You probably don’t want to do this, but it’s a reasonable solution if you’re convinced you do. To do so, you need to modify the code calling Facebook to specify that you want to handle auth on your own. You do this by passing FORCE_DIALOG_AUTH value into the authorize method’s activityCode parameter.

3. The good: Set up Single Sign On properly (recommended)

Unless you have a good reason not to, you should set up SSO. It’s a bit more work, but it’s the best experience for your users.

Buried in the Facebook documentation is a mention about hash codes. Although it’s not obvious in the documentation, Single Sign On requires applications to provide a Key Hash or certificate (I use them interchangeably) of the signature used to sign the application to Facebook. This is used as part of the validation with SSO. When applications are built by the Android development tools, they’re automatically signed using a debug keystore. You need to use this keystore to generate the certificate. Details about the Debug keystore are available in the Android Documentation – Signing Applications.

In order to provide Facebook with information about the signature, you need to pull it from the keystore. On OSX, you do this in the terminal with the following command:

keytool -exportcert -alias androiddebugkey -keystore ~/.android/debug.keystore | openssl sha1 -binary | openssl base64

This generates a short string of characters (which may include characters such as ‘=’ or ‘/’) that identify the signature. This is the certificate or Key Hash as Facebook calls it. Once you have this, you need to give it to Facebook.

Find your application on Facebook’s Developer page (or create a new one if you haven’t set one up already). Once you’re in the application summary page, choose ‘Edit’ on the Settings banner and then pick ‘Mobile’ on the left-hand side. Under the Android section, you’ll see a box for Key Hash. Paste the certificate string from the command above into this box and hit save. Give it a few minutes to propagate and try running your application again. The invalid_key errors should disappear. Keep in mind, when you sign your application for distribution, you’ll have to generate another certificate like you do here and provide that as well.

SSO Weirdities

SSO isn’t completely smooth sailing though, there are a few issues to watch out for.

1. authorize() always shows a page, even if the user is authorized
As far as I’m concerned, this is a bug in the SDK. The workaround is to store the token after authorizing the first time and simply use that instead of calling authorize again while isSessionValid() is true (Stack Overflow has a great example of how to save the access_token using Android’s PreferenceManager). However, unless you want to request an offline_access token, the token will only be valid every 24 hours.

2. Different Access Token formats
The token received from SSO applications are of a different format. There’s a bug open on Facebook’s bug tracker about this, but they can’t seem to track it down despite it being easy to replicate. This isn’t a huge issue, but unfortunately, you won’t be able to parse the user ID of the Facebook User out of the SSO token the way you can from standard access token format

3. UI is inconsistent between SSO and non-SSO
Non-SSO uses a nicer pop-over dialog to show the authentication panel while the SSO panel slides in from the right (and back out to the right after the user finishes). There doesn’t appear to be a way to change this UI, at least without hacking the SDK code directly.

One of the first things I noticed about the protocol is that subscribers are required to have an internet accessible URL for validating subscription registration and receiving notification pings. This is not an issue for the Google Readers and FriendFeeds of the world, but this does leave desktop RSS readers out of the party.

Also interesting to note is that there’s nothing that requires the hub to be a separate entity from the publisher. In fact, it could be very desirable for the publish to own the subscription hub. Besides removing one notification roundtrip from the protocol, it would also give publishers more control over how often to ping users on updates. Nothing in the protocol requires that a notification be sent every time, so it would be possible to only notify a subset of users in real time (perhaps the ones that pay), and others on a regular basis.

Depending on how deep your RSS Trivia knowledge goes, this might sound awfully close to the rssCloud element, but Brett points out that the key differentiator here is PSHB’s “fat pings“, that is, the entire updated content is sent as the ping to the user.

To reduce latency and polling, PSHB supports persistent HTTP connections from hubs to publishers, but it could use FriendFeed’s SUP protocol to detect updates as well.

Though solving slightly different problems, it’s interesting to compare the SUP’s and PSHB’s stance on polling. SUP obviously relies heavily on polling, despite drastically reducing the amount required. While PSHB has strong opinions against. Polling is certainly less error prone, in addition to being less efficient. For example, how does PSHB handle dropped pings to subscribers? I admittedly haven’t dug too deep, but I assume a reasonable amount of state must be maintained in the hub to handle these cases smoothly.

Ultimately the most valuable contribution of the entire project might be the two outspoken Google employees behind it. Already they are seeing some adoption. The pubsubhubbub demo at Real-Time CrunchUp announced launched FeedBurner support and showed prototypes of Blogger and Reader support. Having evangelists inside the company puts early adoption in other Google products much more likely, which in turn will give the standard much more credibility.

Google’s not the first to tackle this problem. ThinkFree and Zoho already have mature offerings. Hell, even Microsoft has their Office Live Premium ($39.95/month). Features vary (Zoho has presentations, MS handles mail and web only). There is obvious demand and interest for such a product. So why is has Google’s entry got enterprises lined up do hand over their data?

Just the name.

Google’s Vice President of Engineering Doug Merrill says that “for the first time, consumer-grade applications are good enough that they can be used by enterprises,” but he’s wrong. They’ve been good enough for a while. For the first time, the applications are backed by a big enough name that enterprises are willing to trust the provider, especially now that the company is asking a fee for the service – a marked departure from the typical web 2.0 business plan.

But not everybody’s ready to dump their exchange server and climb aboard the Google Apps train. There are three problems Google is going to have convincing most companies to switch.

Here’s the first: Google (or anyone else) is going to be hard pressed to match the flexibility of a thick-client productivity suite in a web browser. This is the number one reason people shrug off Google Apps. Some may counter and say “well, 80% of users only use 20% of the functionality,” but it’s never the same 20%. Chances are 80% of the users are going to be slightly annoyed that they can’t find [insert feature here], the other 20% won’t even consider it.

The fix? Well, it depends if you consider it a problem. Google doesn’t. Google has repeatedly said (even after the announcement of PE) that they aren’t aiming to take market share from Office. And there is absolutely no reason that the two can’t exist side-by-side.

I am willing to bet that within a year, Google will release a plug-in for Office that wires the current working Word/Excel/PowerPoint (presentations are coming – don’t worry) document right into Google Apps. Extrapolating, it’s only a matter of time before similar plug-ins are available for all the major productivity suites such as OpenOffice and iWork. Imagine no more file incompatibility issues, the filetype is always Google.

Problem Two: A good number of companies will not feel comfortable having all their sensitive business data floating around outside their network.

Instead of sending your information out to Google, bring Google in with your information (if it isn’t already). Google already offers Google-in-a-box search appliances. There’s nothing stopping them from just installing Google Apps on one of their machines you’ve already got in your wired up to your existing network if that’s what you prefer.

Problem Three: Connectivity

If your office makes the move to Google Apps and the connection to the web goes down, you’re effectively boned. And it’s even more frustrating if the outage is at Google’s end and out of your control. Salesforce.com has already run into this. Google’s 99.9% uptime may not be good enough.

But this problem has a solution on the way. Robert O’Callahan of Mozilla recently announced that Firefox 3 will support offline applications. Properly instrumented, users may not even notice the disconnection.

Where Google Apps will win
Features. New ones.

Google will easily convince CIOs everywhere with their $50/user-year price tag, but they’ll have a riot on their hands if the end users are frustrated by the experience. Google makes very user friendly software, but I’m more concerned about the temptation to try and match Word feature-for-feature and ending up with ones that translate poorly onto the web.

The key is to offer features that are useful, but that users can’t find anywhere else. Google’s already hitting this with their very well done Online Collaboration tool and the automatic revision history (something that should have been implemented in Office long ago).

I’m also excited to see what Google does with their APIs. Integration with the other SaaS movers and shakers such as Salesforce.com or CrystalReports.com will be a tougher feature to match at the packed software level. Expect people to jump the MS ship just for that.

Heads up to opportunists: Learn Google Apps APIs as soon as you can. I have a hunch that integration and migration to Google Apps will be problems looking for solutions in no time at all.