Developer craft and industry

Thinking about developer products means thinking about developers. What is different about software development as compared to other professions or interest groups? In particular, what needs to be considered when building tools and services for developers?

Read More

How DevRel fits the business

DevRel, developer advocacy or developer evangelism teams are a part of almost every recent developer-services success. Many DevRel people are hired for their functional responsibilities (we need someone to do X), rather than how they fit into the business.

Read More

Serverless or Client-ish

Serverless, with all the attendant ambiguity on what that means, tends to be discussed from the perspective of people who build services. This often leads to a focus on the differences between serverless and previous generations of infrastructure. Specifically, we talk about how the provisioning, balancing and so on have been made utility, as compute, storage, hardware and bandwidth had been in previous generations of technology.

Read More

Server Side Google API Access from Android

Back in the dark ages I wrote a blog post on using Google Sign In to authorize a server from an Android client, and provided an accompanying gist with an example Activity in it. Recently, someone point out to me that gist was quite out of date, so I updated it to use the latest and greatest Google Sign In APIs on Android, with very pleasant results.

The new version is much easier to understand, and only 2/3 the length of the previous one, without losing any functionality. That’s possible because of some of the features the Identity and Google Play Services teams at Google have added to Google Sign In, and to Google Play Services itself.

Auto manage

Google Play Services is, as the name implies, a separate service on an Android device, and requires a Binder connection. Back when I wrote my first gist this was wrapped in an API specific client (PlusClient), and more recently in a generic Google Play Services client (GoogleApiClient). Managing this connection took quite a lot of code. All of that has been made vastly easier thanks to the auto manage functionality. That effectively hides a very clean implementation of the connection management and error resolution code in a fragment on your activity, and is enabled like this:

Now, the only callback we have to worry about is the OnConnectionFailedListener. That tells us when there is a more serious problem (for example Google Play Services is missing or being upgraded) - we can’t do much with it other than disable any functionality that needs the service.

The Google Sign In API

Authentication used to be implicit in the GoogleApiClient connection - it would fail to connect until signed in if using an authenticated API. With the Google Sign In API, this changed - the authentication state and the connection state are separate, easier to manage options.

The net result of this is that checking sign in state is much simpler, and done on that Google Sign In API directly:

Here we also see another newer feature of Google Play Services, the OptionalPendingResult. PendingResult is a class which effectively wraps a callback - its kind of like a promise - but OptionalPendingResult extends that idea to allow for results which may be cached in-process. if opr.isDone is true you have a result available synchronously, otherwise you can register a callback for an update.

This is particularly convenient here - if the sign in state is cached locally, you can be signed it right away without having to worry about displaying a waiting prompt. If its not, Google Play Services may have to do a network round trip to check whether you have previously signed in to that app, so it probably worth displaying a lightweight spinner or greying out the sign in options until the result comes back.

Integrated auth code retrieval

In the bad old days you had to use GoogleAuthUtil to retrieve a token, which required a background task and was kind of painful. The Google Sign In API uses a model more similar to the JavaScript implementation, where if you request a token one is delivered with each sign in.

This means that once you get a successful GoogleSignInResult, you can fetch an authorization code from the GoogleSignInAccount associated with it.

The gist from before has been updated but for the best introduction check out the complete Google Sign In Sample and documentation.

Read More

Upgrading & Using Google Sign In on Android

Very quick post on a problem I've seen a few people hit where they are upgrading a project which uses Google Sign In on Android.

Just Tell Me What To Do Already

1. Upgrade your project

2. Connect your Android app, but do not enter a SHA1

3. Go to the old Google Developers/Google Cloud project you were using and copy each client ID used for an Android app (e.g. the debug and release versions at least). 

4. In the Auth > Sign In Method > Google panel, enter the client IDs you copied before. 

This ensures your existing app keeps working, and sets you up for transitioning to the new SDK. 

Why Am I Doing This?

There are a couple of things to know: 
  1. The specific combination of Android package name and SHA1 is unique across Google. It can only exist in a single Google project, and is associated with a single client ID. 
  2. An upgraded Firebase project is a Google project underneath. 
This means if you go through the upgrade flow, attempt to connect your Android app and enter a SHA1 used by an existing project, you will get an error. The tempting thing to do is to delete the client ID in the old project, and add the SHA1 in the new project

The problem with this is that if you have already have an app published using Google Sign In and Firebase 2.x, the sign ins suddenly will be coming from a different Google project, and so will start failing with an "Invalid authentication token" error. 

If you've done that - no problem, just remove the SHA1 from the new Firebase console (you can't remove the last one, but just edit it to something different), re-add them on your old Google project, and whitelist the client IDs as above.
Read More

Distributed Identity

The very first message sent over the precursor to the Internet was a log in attempt. Unfortunately, the system crashed part though, so the very first try was just “LO”. Since then, the explosion of networked systems has lead to an explosion systems to log in to.

Read More

Google Sign In iOS 1.0.0

The new Google Sign In SDK for iOS is out! With a new version number, and separated from the old Google+ SDK, the Sign-In SDK should make it easier and faster to implement Google Sign-In in your app. Lets take a look at how to use it from Swift.

Unfortunately the library isn't available from Cocoapods yet, so you'll have to drop it in manually. Setup is pretty easy: add in the GoogleSignIn.framework from the zip download and add the system AddressBook and SystemConfiguration frameworks. If you want to use the supplied button, you'll also need to add the GoogleSignIn.bundle from the SDK zip which contains the fonts, images and translations for the standard button - using the Add Files to "project" menu option should automatically set it in the Copy Bundle Resources part of your build step.

If your sign in button is invisible when you launch the app, you probably haven't copied the GoogleSignIn.bundle from the SDK zip file.

In the Build Settings phase, add -ObjC in Other Linker Settings (you may need to toggle to "All" from "Basic" at the top). This is needed as the SDK contains categories which otherwise aren't loaded - so if you see any errors around standard foundation classes with suspiciously Google oriented (Categories) on them, missing this flag is likely the culprit.

The final bit of general setup is creating an iOS client ID in the Google Developers Console and setting up a custom URL type, so that the user can be redirected back to your app. The way Google Sign In works is by sending the user to either a Google app or Safari to authenticate, then (on success or failure) redirecting the user to your app. There's no standard way of triggering that redirect on iOS, so we need to have a unique custom URL type set up for each app. My client ID from the console is, so I reverse it for my custom URL scheme.

Note: Those familiar with Google+ Sign-In will remember we used to use the reversed bundle ID, but actually this client ID approach has been supported for some time, and is more reliably structured like a domain name. If you're setting up sign-in for multiple apps, its best to use a different client ID (in the same console project) for each so that the user doesn't accidentally get sent to the wrong one.

Next we have to add a bridging header so our Swift project can access the Google Sign-In SDK. There's a little trick we can use: go to Supporting Files in the project view on the left, right click and select New File > Objective-C File and call it "temp". When xcode asks about configuring a bridging head, say yes. Now delete temp.m, and you have a bridging header file added and configured, which is nice! In that file, add the Google Sign-In header: #import <GoogleSignIn/GoogleSignIn.h>

Now we can use the Sign-In SDK from anywhere in our Swift project. First, lets add our sign in button. Go to your Storyboard, add a UIView and set the class to GIDSignInButton. Its already plugged in to the GIDSignIn singleton, so you don't have to do any setup. Use the assistant to add a outlet to your viewController. For now we'll just hide this button to show we've signed in.

For those familiar with GPPSignInButton note this is now a UIControl rather than UIButton.

We need to configure the GIDSignIn instance in our AppDelegate. We set up the client ID that we generated in the console project (right way round this time), and also pass through the handleURL call so GID can process the callback. Make sure to set the client ID before calling the URL handler though! We would also set any initial API scopes we want to use here by adding them to the GIDSignIn.scopes array property.

Finally, in the ViewController we implement the normal sign in process. First we set the signIn delegate to ourselves, and implement the GIDSignInDelegate protocol. We then attempt to sign in silently - this checks whether the user already has an authentication in the keychain - if they do, and its still good, we'll get the didSignInForUser callback shortly after. If not, the callback will be triggered when the user taps the sign in button and then is redirected back to the app after completing the sign-in flow.

Next, you can do all the normal sign in things like request additional scopes incrementally and authorise a server.

The GIDGoogleUser object there will have a .userID property you can use as a primary key in any user database, and if you set GIDSignIn.shouldFetchBasicProfile or have email in your GIDSignIn.scopes array, you will get the email address in The GIDProfileData object in .profile is pretty helpful for people who want to display an avatar as well - the .hasImage property indicates whether or not they have a profile image available, and imageURLWithDimensions: will give you back a URL for an appropriately sized picture.

There is also a new delegate which is of great use in making a more responsive ui: GIDSignInUIDelegate. This will give you a callback once the sign-in resolution has finished, and the GIDSignInDelegate will be called or the user redirected to the consent screen. This gives you the opportunity to display a activity indicator or hold off activating parts of the UI until you have a known sign in state for the user, which is very helpful in building a more consistent user experience. GIDSignIn also lets you disable signing in with a browser with GIDSignIn.allowsSignInWithBrowser, in case you only want a sign in experience with a native Google app, which can be a lot smoother for the user.

Read More

Understanding Service Accounts

Misconceptions about Google service accounts are at the heart of a number of problems I’ve seen developers having on Stack Overflow and various issue trackers. Hopefully this post will dispel some common misunderstandings, and break down what they are for.

What is a service account for?

Requests to many APIs need to be authorised to access data or services. In most cases this is done interactively with a user - the site presents a sign-in button, the user grants the site access to a part of their Google account, and the site receives an access token they can pass with their requests. Google checks this token to ensure the query is allowed to access the data it is requesting.

However, there are some situations where the user is not actually present - for example a daily batch script which downloads data from a Google Analytics account, or a process which provisions services for a Google Apps user when a new staff member starts at a company. In these cases, a service account is used to retrieve that authentication token rather than an interactive exchange. Normally service accounts are a "server side" or offline access method, so you are very unlikely to use them from browser Javascript, or and Android or iOS app.

How do service accounts work?

A service account is a sort of virtual user or robot account associated with a given project. It has an email address, and a cryptographic key pair. Google keeps one part of the key, and the developer keeps the other. To authenticate, the developer creates a request for an access token and signs it using the key. The request contains information on the service that the robot account wants to access. Google’s auth services process this request to check the service account should be able to access those things, verify the signature, and if all is well return an access token.

This access token authenticates a request as being from the service account user. This is the step that causes problems for many people - because they created the service account in their Google Developer Console project, they assume that the tokens that the service account retrieves represent them - but it doesn't, it represents this virtual user and all Google knows about it is that it is a member of a certain console project. In most cases, that virtual user needs to be granted specific access to anything you want it to be able to retrieve.

Accessing data and services.

For APIs that can be used without authentication, such as the Google+ search API, authenticating with a service account will just associate the call with your Developer Console project. This can be valuable, as it allows increased quota over and above the anonymous access, but you could equally use a Public API access key, which doesn’t require retrieving a token.

However, in most cases the service account is useful only if it can access some user data - but it itself doesn’t have any. The solution is delegation: granting access to the service account to specific user data. The easiest way to see this is to walk through some scenarios. Note that these things do change over time, so if you’re reading this some time after it was written things might be in a different place, but hopefully the general approach should still work.

Creating a service account

Visit the Google Developers Console and select (or create!) the project you want to use. Then in APIs & auth go to the Credentials option. Select Create Client ID, and select type Service Account.

When you click OK, you’ll download a .p12 file in your browser, and see an entry with an email address in it, something The .p12 file is your part of the cryptographic key, so treat it as a secret, and don't lose it! You can generate a new one from the console, but you can't download this one again.

Next you need to enable access to any APIs the service account wants to use. This doesn't give you access to user data, instead just enabling the account to query those APIs at all. Under APIs & auth go to Apis and switch on the services you need - if you're following along with this post choose the Analytics API and Drive API.

Now we can look at how you actually grant service accounts access to a couple of different sets of user data.

Accessing Google Analytics data

The Google Analytics API offers you pretty much complete access to the stats about your site or app, but a service account wont be able to see any of it unless you have granted it access. With analytics this is done by adding the service account email address as a user to your Analytics account. Simply access Analytics, go to the Administration > Property Permissions section and select the User Management settings. At the bottom you’ll see an Add permissions for box, which takes an email address. Add your service account email address from the developer console here.

Once that's done, we can retrieve an access token for the service account user, using the scope, and query the API just as we would if we had a user signed in via the regular OAuth 2.0 flow. In this case we aren't pretending to be a regular Google user at all - we've specifically granted our robot account access to view our analytics data.

This code is PHP, but the flow should be similar with any of the Google API client libraries. Walking through it, we:

  1. Setup the values for our service account - its email address and the location of the p12 file primarily.
  2. Load in the key file and create an assertion for the Google Analytics scope.
  3. Call refreshTokenWithAssertion to get a new access token.
  4. Query the API.

It is worth noting that the call to get an access token is a little expensive - if you're going to be making multiple calls definitely cache the access token, and only refresh it with the service account when it expires.

Access Google Drive for a Google Apps User

Google Apps domains are designed to be administered through a variety of tools, so come with a more flexible delegation model than just approving the email address like in Analytics. You can actually approve a service account to act on behalf of the users of a Google Apps domain with a predefined set of scopes via the Apps admin console (you can read more about it on the Google Drive delegation page).

Adding an account is done through the Admin page under Security - Advanced Settings (under More) - Manage Api Client Access. To allow access you enter the service account client id (not the email address) and the scopes you wish to access. In our case that's the scope.

We also have to take an extra step in our code and specify precisely which account we want to access, as it could now be any valid user under the apps domain. We use the sub (subject) parameter on the assertion credential to indicate this by setting it to the email address or the Google user ID of the user we want to act on behalf of. Take a look at the following snippet as compared to the analytics one above - other than the service and scope the only difference is that additional sub parameter.

As a follow up to the note about caching above, be aware that the tokens will be different depending on the sub and scopes requested, even if they're from the same service account. For example: if you cached the token from the Analytics query and then the token from the Drive query, they would be different and not have access to each others resources. Be sure to include the sub, scopes parameter, and service account email address in any cache key generation you do.

Anything else?

Service accounts pop up in all sorts of places, each with their own delegation methods. For example, Google Cloud services have automatic service accounts made available in Compute Engine and App Engine to make querying the Cloud APIs easier. In this case you may grant the scopes via the gcloud command line tool and retrieve the access token via calling a special endpoint. In general with the Cloud services you do not have to worry about delegating access as the data they query is generally owned by the project (for example with a service like Cloud Storage) rather than a specific user.

Hopefully this has made the service account idea a little clearer - they're a powerful tool for background or batch access to APIs, but can easily be confusing (like most auth related topics). If you’re having trouble with one make sure you have correctly configured access for the service account in the admin controls of the relevant API, and that you have requested the appropriate scopes and subject when creating the token request assertion credential.

For more information on service accounts, check out the official documentation, and for any thorny questions try the google-oauth StackOverflow tag.

Read More


Knowledge workers place a great deal of value in concentration and focus. Understanding systems and solving problems requires attention, leading to heated debates over the best kinds of noise cancelling headphones or whether it is really necessary to attend this or that meeting.

Read More

Upgrading to Google Cast iOS SDK 2.4.0

Recently I've been working on the samples for the Chromecast SDK on iOS. Since we've just updated the sample app for the brand new 2.4.0 SDK, I thought I'd briefly note down the changes I had to make, which should help if you need to update your own app from 2.3.0. As always, the full list of changes can be found in the release notes.

Update Frameworks

The first step is to drop the new GoogleCast.framework into the project. You'll immediately notice that some classes have changed, and that there is a new dependency on SystemConfiguration.framework, so add that in your Linked Frameworks and Libraries section in the General Project Settings.


To simplify the scanning and connection process, filtering has been merged right into GCKDeviceScanner. Start by removing any references to GCKDeviceFilterListener or GCKDeviceFilter as this functionality is now part of the GCKDeviceScanner directly. Remove any of the delegate methods you may have implemented in GCKDeviceFilterListener, but keep the contents - you can use the same in the GCKDeviceScannerListener methods.

Remove any references to add/removeDeviceFilterListener, then move the contents of: deviceDidComeOnline:forDeviceFilter: into the GCKDeviceScannerListener method: deviceDidComeOnline:.

For deviceDidGoOffline:forDeviceFilter:, use the GCKDeviceScannerListener equivalent: deviceDidGoOffline:.

Where you would have initiated scanning by creating a GCKDeviceFilter with criteria and a scanner, you now attach the filter criteria directly to the GCKDeviceScanner. Keep your GCKFilterCriteria object, and instead of calling initWithDeviceScanner:criteria: simply attach your criteria object to the filterCriteria property on your GCKDeviceScanner: self.deviceScanner.filterCriteria = filterCriteria;

Listing Devices

Where you would have iterated over the GCKDeviceFilter.devices array to get the currently discovered devices, you can now use the GCKDeviceScanner.devices array directly. Replace all references to the filter array with the GCKDeviceScanner devices one.

There is a gotcha here to be aware of though! The devices array is updated after the deviceDidGoOffline call is fired. If you're using that callback to update whether or not the Cast icon appears in your app, you might hit trouble. The solution is to do your UI update in the next runloop, which you can easily do with performSelector. In the CastVideos sample, we do exactly that:


The other class that has received significant attention is GCKDeviceManager, with new properties and callbacks to give you more information, or easier access to that information. Some of these will require changes in your code though.

The GCKDeviceManagerDelegate method deviceManager:didReceiveStatusForApplication: has a new name. If you implemented this method, update it to the new signature: deviceManager:didReceiveApplicationMetadata:.

If you were listening for deviceManager:didDisconnectWithError to pick up network based disconnections (e.g. the WiFi disappearing), there is a small issue that that this wont fire if you disable the WiFi on your device, which you may do when testing or similar). However, you can listen to the new deviceManager:didSuspendConnectionWithReason: and will get a callback with the reason GCKConnectionSuspendReasonNetworkError (see Connection Suspension below) in any case.

Error Handling

One wider change is that many GCKDeviceManager methods now return an NSInteger containing the request ID rather than a BOOL, with immediate failure indicated by the value kInvalidRequestID, which conveniently is 0. This allows tracking whether requests subsequently fail, thanks to a new delegate protocol method: deviceManager:request:didFailWithError:.

Connection Suspension

There are new delegate methods as well for suspended and resumed connections, didSuspendConnectionWithReason and deviceManagerDidResumeConnection:rejoinedApplication. Suspended indicates the connection has been interrupted, but the device manager will attempt to connect automatically. You shouldn’t use this method to force a reconnection, but you might want to hint in the UI that the Chromecast device isn’t going to respond immediately to commands. GCKConnectionSuspendedReason is an enum indicating whether the suspension is due to the app being backgrounded, or a network related problem.

Device Status Text

The device manager protocol also has new status information callbacks. One of the most useful is a text field describing the currently running application: deviceManager:didReceiveApplicationStatusText:. This will contain "YouTube TV" or similar to indicate the app currently running. This can be helpful to display to users in case there are similarly named Cast devices on their network. The same information is conveniently available on a GCKDevice directly as the statusText property.

Launching An App

Finally, if you were previously using launchApplication:relaunchIfRunning: then its worth noting that method has been deprecated in favour of a more extensible launchApplication:withLaunchOptions. The second parameter is a new GCKLaunchOptions object. To recreate the old call, you can use:

Read More