ecently, Google released its robust “Google Data API” with little fanfare. In fact, if you aren’t an avid tech blog reader or didn’t go to Google Developer Day, you might have missed it. Upon inspection, it’s clear that Google did not have the mobile developer in mind when mapping out these APIs, but that doesn’t mean you can’t make the most of the tools they’ve released. While Google has made pre-compiled libraries available for several higher order languages (from Java to Python), as Brew developers, you will have to take the hard road and use HTTP. However, since the HTTP protocol API is the least common denominator, it will work well on any system with a decent HTTP/HTTPS implementation.

In this article, you’ll learn to add basic Calendar functionality to your mobile application and how to get the XML feed for a public calendar and login through secure HTTPS. Along the way, you should get a good sense of how to use IWEB and Brew’s straightforward implementation of SSL. This article is meant as an introduction to Google’s API, not a tour de force. Stay tuned to this site as forthcoming articles will deal with J2ME development and more complicated features.

Carefully Consider Your Options
Before diving into writing some Brew code, you have a very important decision to make. Integrating your Brew application directly with Google’s web service can have some dangerous consequences. This issue is a classic conundrum in the mobile world. Do you integrate directly with a third party’s servers or do you write a server layer to bridge your Brew application and the third party service? It’s important to point out a few things to consider before coming to a final decision. First, if Google “updates” its API without support for backwards compatibility, your application will fail to interact with the service. This could have the nasty side effect of forcing you to resubmit your application to NSTL. Second, Google could remove the service entirely, forcing you to remove your app from the catalogue or disable portions of it. Recently Google removed its SOAP search API, much to the chagrin of the developers who made use of it. Fair warning: just because it’s working now doesn’t guarantee that it will continue working in the future.

The alternative has its drawbacks as well. Developing a server layer adds to your costs?which can be far more expensive than a round of NSTL submits. Additionally, you’ll have to pay for the bandwidth and CPU time for your server middleware. At the least, I’d suggest sending the traffic through a simple proxy you control, so at some later date you could modify your server to follow the changes in Google’s API.

You’ve probably had enough warnings and doom and gloom; let’s look at some code.

Retrieving a Public Feed
The first, and possibly simplest, way you’ll interact with the Google calendar API is to retrieve an XML feed for a public calendar. It’s a great place to start because it involves one (sometimes two) simple HTTP get requests and no cookies or tokens. First, make sure the calendar you want to access is public. Once that’s done, you should be able to access it through this simple function:

static void GetCalendarStream(void *pData){	GApp *pme = (GApp*)pData;	char *szPostHeader;	ISourceUtil *pUtil;	IPeek *ppeek;	ISHELL_CreateInstance(pme->a.m_pIShell, 		AEECLSID_WEB, (void **)&pme->pEventWeb);	CALLBACK_Init(&pme->clb, CalCallback, pme);	szPostHeader = MALLOC(200);	SPRINTF(szPostHeader, "Content-Type:application/atom+xml
");	IWEB_GetResponse(pme->pEventWeb,(pme->pEventWeb, &pme->pResp, &pme->clb, "http://www.google.com/calendar/feeds/[email protected]/public/full",		WEBOPT_HEADER, szPostHeader,		WEBOPT_METHOD, "GET",		WEBOPT_HANDLERDATA, pme,		WEBOPT_HEADERHANDLER, EventHeader,		WEBOPT_COPYOPTS, TRUE,		WEBOPT_END));	FREE(szPostHeader);	}

This is a fairly straightforward example of an IWEB GetResponse call. You’ll need to set the content type in the headers by hand. Google specs out the feed URL as follows:

"http://www.google.com/calendar/feeds/*email-address*/*access-level*/*feed-level*"

In the previous example, you can see that you’ve looked up a non-existent [email protected] account. This example requests only public events (hence the “public” access level) and full details on all those events. To read calendars that have not been made public, you’ll have to log in. You’ll see more on that later.

Now that you’ve requested all this data, how do you receive it? The easiest thing to do is write it to a file. Listing 1 shows you how to capture it.

Make sure the connection was successful and then, using a basic readable loop, pull the data over the network connection and write it to a file. While this process is interesting, it provides limited opportunity for getting the feeds for public calendars. In order to achieve more interesting results, such as letting users add events to their calendar or request a private feed, you’ll need to fix it so they can log into their Google Calendar account.

Logging In
Logging in is a little bit more complicated than grabbing the public feed. The process can be a multi-step endeavor requiring tokens, SSL, and eventually even cookies. Google’s documentation outlines the process for logging into a calendar account. First, you’ll need to POST to this URL:

"Email=*email_address*&Passwd=*password*&service=cl&source=Devx-Sample-Code-1" 

over HTTPS to:

https://www.google.com/accounts/ClientLogin.

Listing 2 shows the function to accomplish the post.

While it may be a review for experienced Brew developers, let’s break down Listing 2‘s code a little bit. First, you’ll need a few Brew objects. You need an SSL root cert to use https, an IWEB object to make the request, and a SourceUtil to format the post data for the IWEB object. Next, you can use CALLBACK_Init to set up your response callback function. In this example, the post data is hard coded to [email protected] and a simple password. You’ll probably want to pull this information from a text control or previously cached login info. Note the “service=cl”. This tells Google’s servers that you want the Calendar service. Google’s documentation also specifies the required content type, so you’ll have to placate them and put “Content-Type:application/x-www-form-urlencoded” in the header.

Now that you have all your data, turn the post into an ISource and post the data over IWEB. Then it’s just cleanup and return. As always, it’s important to guard resources and memory allocations to keep your application from crashing in low resource situations.

Once you’ve sent out the post, you’ll have to wait for the callback containing the authentication token. For reference, here’s the function.

static void LoginCallback(void *pData){	char *szResp;	WebRespInfo *info;	GApp *pme = (GApp *)pData;	if(info->nCode == 200 && pme->pResp)		info = IWEBRESP_GetInfo(pme->pResp);	else	{		DBGPRINTF("Web Resp Failure");		return;	}	//bla = IWEB_GetOpt(pme->pWeb, WEBOPT_HEADER, 0, &lOpt);	szResp = MALLOC(info->lContentLength+1);	ISOURCE_Read(info->pisMessage, szResp, info->lContentLength);	//szResp = (char *)lOpt.pVal;	if(bla = info->lContentLength)		pme->szToken = szResp;}

The above function should look a lot like Listing 2. Allocate a pointer to hang on to your authentication token, which should be returned to you in the body of the response. Google requires that you put the token returned on the line “Auth=” into the header of your next request as “Authorization: GoogleLogin auth=”. Now that you’ve got your login token, the rest of the information private to the account is available to you.

Go Code!
Using what you’ve covered in this inroductory, you’ve got examples for basic IWEB use, the steps necessary to grasp the XML feed for a public Calendar feed, and an example of using SSL to allow users to login to Google from within your mobile application. Perhaps you could use a public Google calendar to list upcoming events related to your application. Additionally, the process for logging into the Calendar is nearly identical to logging into other Google data services. Stay tuned to DevX for further, more advanced, examples for using Google’s powerful Data API. As Google told us on their website, and on Developer Day: “Go Code!”