Google I/O was pretty busy for Google+ all round, and that includes from the point of view of anyone developing on iOS: we had (at my count) at least 25 iOS apps appearing from various partners at Google+ sandbox, there were a bunch of great questions coming our way at the developers sandbox, and on top of that my friends +Silvano Luciani and +Xiangtian Dai presented on integrating Sign-In, which you can watch on YouTube (or here!):
One bit of news that might easily have been missed was that there was a new version of the iOS SDK released, version 1.3.0. This was a pretty small release for features, but incorporates a lot of feedback from developers, and addresses a couple of common issues.
First, and possibly most helpfully, the various components have been packaged up as frameworks. There are now three packages in the SDK:
- GoogleOpenSource.framework - the open Google Toolbox libraries, and the Google+ services
- GooglePlus.framework - the headers and library file for the Google+ iOS SDK
- GooglePlus.bundle - the translation strings and image assets for the Google+ Sign-In button.
This means adding the files is just a case of dropping in those frameworks, but it does mean that when upgrading you have to change imports to refer to the classes inside the framework name, e.g. #import <GooglePlus/GooglePlus.h>. Helpfully, that GooglePlus.h header includes all of the files you need, so unless you’re keen to minimise links, you can just drop that in and forget about it.
The second feature is something I had completely missed, and only realised from watching XT demo the functionality! Rather than having to construct a GTLServicePlus, and pass it an authenticator, you can now actually get that directly from the GPPSignIn singleton via the plusService property:
Note that you might get yourself into trouble if you try this with a GPPSignIn that is not signed in - the authenticator wont be set, and you’ll make unauthenticated calls. In the future, the team may have the library return nil for the plusService if its not authenticated, which should hopefully make this more obvious!
The third thing that was made easier was a common question from developers - how can I make sure I have an access token, to send to a server for example? In the background, the SDK holds a (hour-long) access token and a (long-lived) refresh token for you, and after the user interactively signs-in both are available. However, because the access token is relatively short-lived, only the refresh token is written to the keychain. This could cause a bit of confusion: when the user starts an app again and is signed-in smoothly with the trySilentAuthentication method, the sign-in delegate would get a callback, but then when it tried to grab the access token, the response would be nil as the SDK has only checked for the presence of the refresh token.
This would be taken care of automatically when calling GTLService* functions, and it was always resolvable by calling the authorizeRequest: method on the GTMOAuth2Authentication object (for example, with ‘nil’as the request) to force a token to be generated, but that was not entirely obvious! In version 1.3.0 and up that is handled for you, so you can just grab the token and carry on. This also has the nice property that if the user has disconnected your app, then on calling trySilentAuthentication you’ll receive a callback to didFinishWithAuth:error: with the error argument set appropriately.