It has been fantastic to see so many people trying out Google+ Sign-In, and through the bootcamps and other events I’ve had a chance to talk to some people who are actually implementing it in their apps. The Android integration is pretty straightforward, thanks to Google Play Services, but there are still some issues I’ve seem come up a couple of times.

As part of the release of Google+ Sign-In, some people have noticed that signing in via the Sign In button doesn’t redirect them to Google, then back to the site, as would have happened if they’d been using the basic OAuth 2.0 flows.

This is as much an aide-mémoire for myself as anything else, but in case you’re using the Objective-C Google API client, you may at some point need to use the simple API access method. This is where you pass an API key to identify the call as being under a certain project, rater than using a full OAuth2 authentication flow. This doesn’t allow access to personal data, but does mean that any calls will be tracked under the quota for your project, rather than a (lower) IP based quota.

One pretty common request around Google+ hangouts is the ability to programmatically schedule them, and have a URL which everyone can join in the future. This is useful for being able to send out links beforehand, and make sure people are ready to go.

At Devoxx the other week I spoke about Clojure, and as an example looked at how it could be used to access the Google+ public data API. Because the Google+ APIs are part of the general Google APIs Discovery Service we looked at how to process and generate functions to call this library automatically (more on which in later blog posts). However, for use now the easiest way to access any Google API via Clojure is probably via the Java client libraries using the Java interop in Clojure.

I was reminded of one of my pet social peeves as part of a conversation with one of the, astonishingly smart, Google interns. One of the most challenging aspects of social networks is that, broadly, people within companies don’t really know what “doing a good job” looks like. Depending on the organisation, social media can be part of marketing, PR, customer service, a specialised department, even IT. The aim of these departments is often mis-matched with the potential or the audience the brand has across their social media, so it is difficult to create effective performance measures.

It’s pretty straightforward to use synchronous encryption over ZeroMQ - just a case of encrypting and decrypting at each end with some previously shared key. Asynchronous encryption is a bit more interesting, as it allows signing for message integrity and authenticity, as well as data hiding. There have been some good examples of crypto over Pub/Sub (notably Salt), but not a lot of examples of direct messaging.

Had a question earlier about whether it was possible to retrieve comments from an event on Google+, and the answer is yes! As long as it’s public, you can grab it via the REST public data APIs.

The History functionality in Google+ is an interesting answer to a pretty common question of “where’s the write API?” It allows creating moments in a user’s (private) history, which can then be reshared. It’s currently in developer preview, for the express purpose of getting feedback on the API.