Risk Complete Failure

Recently I've answered a couple of questions from people that had a section of their site loaded dynamically with Javascript, and wanted to put a +1/Sign-In/Follow/etc button there. Google+ Sign-In along with all the Google widgets, can be marked up in HTML and rendered automatically when the plusone.js loader is included in the page. However, there are ways of controlling when that happens with explicit parsing, or triggering it directly with the render functions. Lets say we have a page that contains a +1 button, a follow button and a post embed, though the same thing works with sign in, badges, and anything else. The most straightforward way to write that page is by using the markup based widgets, which all follow a similar form and look something like this. Pretty much all the other widgets work the same way: a known class name which is scanned for when the async tag loads, and a series of parameters on the element specified as data- attributes to configure the behaviour

One of the questions that you face as a developer when implementing Google+ Sign-In (or any login method) is how to present the options to the user. Having reviewed a pretty large number of apps with sign-in, I thought it might be helpful to break down the four main approaches for displaying the buttons that I've seen, and some thoughts on the costs and benefits of them. A couple of points before we get into that: It's worth remembering that the best situation is when the user does not have to take any action at all. That's the idea behind cross platform single sign on and over-the-air installs . It's also why it is worth taking the time to make sure users stay signed-in after an app upgrade or releasing a new version of a website. Secondly, unless there are solid reasons not to, sign-in should always be paired with sign-up. Particularly on mobile devices this can be a missed opportunity where users are expected register on the web first. That said, in this post I

NOTE: This blog post is pretty old! Take a look at a much better way of getting an authorization token or check out the official Google Sign In documentation for a more up to date (and easier!) choice. Google+ Sign-In is a really easy way to authenticate and identify a user and build interesting experiences on Android. Some apps needs more than just an authenticated Android client though - they also need to make Google API calls from their server, perhaps even when the client is offline. Enabling both to access the APIs at the same time is slightly tricky, but in this post I'm going to try and break down what is required, and how you can do this in a robust and reliable fashion. Note that life is much easier if you just need either the client or the server to have API access, or just need to identify the user to a server. This approach is solely for the case where you make Google API calls on the Android client, and also Google API calls from the server. Our model is that we

There have been some interesting things happening with Google Analytics that have made it even more useful for developers recently. The Google Play team announced that you can now track app install referrals using Analytics, and on the web side the Analytics team have started rolling out Demographics and Interests information . Demographic data is a great way of getting a view of how the usage of your web app varies with the age or gender of the person using it. This is powerful, but it got me thinking about how you might do the same thing within a mobile application. Some of the same information is actually available via a user's Google+ profile. By integrating Google Analytics into your application you can get measures of the usage of various parts of the app, and by grabbing the age range and gender from Google+ Sign-In you can look at how the different flows break down by the demographics of your users! Setting up Google Analytics This is done through use of a feature c

With all the share box related things happening over the last week or so, I realised there are a couple of non-obvious parts of the Android PlusShare class which might be of interest to people. Google Play Services Share box I actually had to test for myself to verify this feature of Google Play Services, which I was aware of but hadn't actually tried! If you are building an app which include Google+ sharing, you might be used to it firing an intent to the Google+ app which gives you the familiar Google+ sharing experience. Because the Google+ app comes with many devices, you may not have worried too much about what would happen if it wasn't available, but the Google+ Android platform team did. So they actually built a backup share box right into Google Play Services. You call it just like you would with the regular share box - if Google+ is installed it will be used, otherwise the Google Play Services share box will be handle the intent instead. Its a little bit simp

I previously mentioned how easy it is to deep link straight into the Google+ app on iOS, to view a user's profile or similar, using the gplus:// scheme and UIApplication openURL . This sort of integration is pretty much the only way to do general inter-app communication in iOS (bar the new audio APIs), and several other Google apps offer their own URL schemes which let you make very straightforward integrations. Mostly these are ways of giving users a slightly smoother experience when entering the app, but one allows you to do a little bit more! Google Maps With Google Maps, you can specify coordinates to focus on, a search to perform, or two locations to ask for directions between. All the parameters are documented on the maps site . As a simple example, searching for pizza near me looks like this: Gmail With Gmail you can go straight to the compose screen and specify the to and the subject line, just like with web mailto:// addresses. This can be good for email opti

After the recent iOS 1.4.0 SDK update that allowed sharing images straight to Google+ from within an application, a couple of people asked whether it was possible to do the same thing on Android. Luckily, it is, and it is very straightforward. The PlusShare.Builder class has an addStream method which you can use to attach an image when configuring a share. Note that just like on iOS, you can't use it while attaching a URL, or as part of an interactive post. The method takes a URI, and will add it to the intent as a standard EXTRA_STREAM . There's also setStream , which overrides any previously attached streams. All we do in the snippet below is trigger a picker intent to allow the user to choose an image from the gallery. We then create a share builder and add the returned URL. Note that this usage is not passing a PlusClient when creating the Builder, so it will work for users that aren't signed in with Google+. If your users are, then definitely use the version th

I'm really happy to see the release today of version 1.4.0 of the iOS Google+ SDK. It's worth a look , in no small part because the team have fixed one of the longest standing requests for the SDK: the ability to share to Google+ without the user leaving the app. In previous versions of the SDK, the only sharing option was via the mobile browser, so the user would be switched out of then back into the app they were using. This release puts the share box fully inside the app for signed in users, and has also given it a bunch of new special powers for better sharing. All of the documentation on the Google+ iOS developer site has been revised and improved , but I wanted to highlight my favourite parts of the release here as well. Native Sharebox The new share box is a smoother way for users to share from within your application to Google+. The existing share box that calls out to the browser and back is still available for anonymous users, but if you're implementing Goog

The latest update to the Google Play Services client library on the 20th of September had a couple of Google+ changes in it that the docs were a bit slow to reflec. Though they're now all up to date, I wanted to quickly highlight the changes in a post as well, for anyone looking at the client library. PlusOneButton no longer requires PlusClient No longer do you have to worry about calling clearScopes() on your PlusClient before creating a +1 button in an Android app. The PlusClient argument has been removed from the initialize methods on the PlusOneButton class, which means creating a +1 button is now as easy as adding it to your layout file: We set up the button by calling the initialize function with a URL, and either a request code or a click listener. loadPerson is dead, long live getCurrentPerson The people loading functions were simplified as well. The PlusClient.OnPersonLoadedListener interface and the PlusClient.loadPerson method have both been remov

At my talk at Over The Air 2013 this weekend in the wonderful Bletchley Park, one thing that surprised some people was the fact that Google has a OAuth 2.0 option for low capability devices . This is one of the big benefits of using Google as an IDP - it allows you to take advantage off all the work that the identity and security teams do in areas like 2-factor auth, data management, and access for all sorts of different environments. The devices setup is really for cases where you want to allow a user to sign in to something that doesn't have a great control setup - for example a TV or a wifi-enabled toaster. With it, the user only needs to indicate that they want to sign in, but they actually authenticate in a web browser on a regular PC or their mobile device. You can take a look at how it works below. This iframe is representing a device that you might want to sign in to, and as soon as you click the Sign In button below, it'll try to sign in and give you a code. You&#