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.
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
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
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
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
has been updated to make
http://www.blogger.com/feeds/ the base
service URL until the Blogger https issue is resolved, so things just
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
EXC_BAC_ACCESS errors with a stack trace similar to the
1 2 3 4 5
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.
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.
There is currently a linker bug
that requires you to add
-ObjC and either the
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.