Greg |
Tom |
Four years ago, we introduced an Objective-C library for Google Data APIs. At first, it supported a scant three services - Google Base, Calendar, and Spreadsheets. Perhaps more surprising is that it was written just for Mac applications; the iPhone SDK was still a year off. In the years since, the library has grown to support 16 APIs, and has been used in many hundreds of applications. In a fine example of unforeseen consequences, most of those applications run not on the Mac but on iOS.
The Google Data APIs were built on XML and the Atom Publishing Protocol, a reasonable industry standard for the time. But mobile, low-power, and bandwidth-limited computers are now the biggest audience for client software. Across the Internet, XML and AtomPub have given way to the lighter-weight JSON data interchange format.
Other fundamental changes have also shifted the API landscape. Password-based authentication is being supplanted by the more secure and flexible OAuth 2 standard. The number of APIs has grown dramatically, making it impractical to hand-craft data classes for all APIs and all languages. When services offer API improvements, developers want access to those changes as quickly as possible.
To support this evolving world, we are introducing a brand new library for Cocoa developers, the Google APIs Client Library for Objective-C. The library supports recent Google JSON APIs, including Tasks, Latitude, Books, URL Shortener, and many others. It is designed to make efficient use of the device’s processor and memory, so it’s a great fit for iOS applications.
The new library includes high-level Objective-C interfaces and data classes for each service, generated from the Google APIs Discovery Service. This lets the library model data not just as generic JSON dictionaries, but also with first-class Objective-C 2.0 objects. The classes include properties for each field, letting developers take advantage of Xcode’s code completion and syntax and type checking.
Here’s how easy it is to use the library and the new Google Books API to search for and print the titles of free ebooks by Samuel Clemens:
#import "GTLBooks.h"The library supports Google’s partial response and partial update protocols, so even items of data-rich APIs can be retrieved and updated with minimal network overhead. It also offers a simple, efficient batch model, so many queries can be combined into one http request and response, speeding up applications.
GTLServiceBooks *service = [[GTLServiceBooks alloc] init];
GTLQueryBooks *query =
[GTLQueryBooks queryForVolumesListWithQ:@"Mark Twain"];
query.filter = kGTLBooksFilterFreeEbooks;
[service executeQuery:query
completionHandler:^(GTLServiceTicket *ticket,
id object, NSError *error) {
// callback
if (error == nil) {
GTLBooksVolumes *results = object;
for (GTLBooksVolume *volume in results) {
NSLog(@"%@", volume.volumeInfo.title);
}
}
}];
When we introduced the previous Objective-C library, it was with this assertion: When you trust your personal data to Google, it's still your data. You're free to edit it, to share it with others, or to download it and take it somewhere else entirely. We hope the new library and Google’s growing collection of APIs help iOS and Mac developers to keep that principle meaningful for many years to come. You can start using the Google APIs Client Library for Objective-C by checking it out from our open-source project site and by subscribing to the discussion group.
Since Google I/O 2010, we've been developing APIs that can provide descriptions of themselves via metadata. This new technique makes it easier to create and maintain client libraries that support more languages, work with more APIs, and are easier to use than ever before. This post announces one of several recent major milestones for our client libraries.
Greg Robbins writes code to connect Mac and iOS apps to Internet services. He chases dogs in the morning, and bugs in the afternoon.
Tom Van Lenten is a Software Engineer on the Google Chrome team. He is also hooked on the Google Toolbox for Mac open source projects.
Posted by Scott Knaster, Editor
No comments:
Post a Comment