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.