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.