GData Objective-C Client

3 minute read Published:

I’ve recently been working on an iPhone application that integrates with Blogger, and as such I have gotten some experience with the GData Objective-C Client Library. The issues below were all encountered while working with the GDataServiceGoogleBlogger service, but they should apply to the other GData services too.

Authorization Scope

The GData APIs support OAuth for authorization. One of the first things you need to do when initializing a GData service is to decide which authorization scope you’re going to use. The various service implementations have a [Service authorizationScope] method that you can use, but it may not always be the best option.

The default authorization scope for Blogger is https://www.blogger.com/feeds/, but the Blogger API does not consistently return links that use https for the scheme. You have a few options to deal with this issue. The simplest is to just use a scope of http://www.blogger.com/feeds/. Another option is to request an authorization scope for both http and https by specifying them together, separated by a space. The downside of this approach is that Blogger will be listed twice when the user is redirected to Google to authorize your application, which I think looks weird for the user. Finally you can correct the scheme portion of URLs before submitting requests with them, but that won’t work for all API calls, such as for deleting entries.

Also note that some links included in responses may not match the authorization scope at all, for example the http://your-blog.blogspot.com/feeds/posts/default feed URL. The OAuth Playground is an excellent tool for experimenting with the various GData APIs.

Update: The latest version of GDataServiceGoogleBlogger has been updated to make http://www.blogger.com/feeds/ the base service URL until the Blogger https issue is resolved, so things just work now.

Retain Feeds

Something which may not be immediately obvious is that you must retain a feed if you’re going to retain any of its entries. Failing to do so can result in EXC_BAC_ACCESS errors with a stack trace similar to the following.

#0 0x002c646c in xmlStrdup #1 0x0027580f in xmlCopyPropList #2 0x00089ec5 in -[GDataXMLNode XMLNodeCopy] at GDataXMLNode.m:879 #3 0x00089c0c in -[GDataXMLNode copyWithZone:] at GDataXMLNode.m:843 ...

The issue here is that a feed’s entries refer back to the feed, but they do not retain it. This can be particularly frustrating to debug, as none of the usual NSZombie tricks work, presumably because the failure is occurring down in libxml2 code.

GDataHTTPFetcher Logging

The GData APIs have a very nice logging feature that you can enable with the following code. You can include it pretty much anywhere in your project.

[GDataHTTPFetcher setIsLoggingEnabled:YES]

There is currently a linker bug that requires you to add -ObjC and either the -all_load or -force_load options to the Other Linker Flags section of your build target. Once you’ve done that, you can find the logs deep within your home directory. Mine showed up in ~/Library/Application Support/iPhone Simulator/4.1/Applications/<some UUID>/GDataHTTPDebugLogs.