Here are my slides for the OKC Java User Group lightning talks tomorrow on Google App Engine. Enjoy!

As you might have heard, Google Voice now allows you to use your own existing phone number with their service. Nice, but you will lose some features otherwise available to you.

While I have given out all of my Google Wave invites, I happen to have some Google Voice invites I can give out. Leave a interesting comment and I’ll use a completely arbitrary criteria to decide who will get an invite.

Use a service like emailcover.com to hide your email address. Even gmail isn’t immune to spam.

By default the Google Wave interface in Firefox on a PC has a lot of thrown at you. I was curious how the service looked on a small device, in this case, an iPhone.

First thing out the gate was not reassuring. Yes, it’s a dreaded “unsupported browser” message:

From Google Wave on the iPhone

Of course there’s no fun in stopping there, I had to go further down the rabbits hole by telling Google I wanted to proceed anyhow.

From Google Wave on the iPhone

Yup, it’s a listing of waves in a webpage clearly designed for a mobile device. In this case, a listing of waves in my inbox.

Naturally I had to take a look at how a wave is displayed.

From Google Wave on the iPhone

More screenshots can be found in my Picasa web album cleverly titled “Google Wave on the iPhone“.

Overall it is clear a lot of effort has gone into making Google Wave work and display well inside of a browser.

Performance was another issue altogether. Despite visiting Google Wave on a wifi connection, the site dragged so bad it was effective unusable. On a second visit performance was quite a bit snappier. I shutter to think about the performance if I was to use 3G or even Edge.

As a food, spam is good

I’ve been noticing an alarming increase in spam making it through Gmail’s spam filters. After talking with a friend about it at lunch last week, I suspect I’m not alone.

Kevin C. Tofel asks Is Gmail’s Spam Filtering Failing For You, Too?.My answer is a solid yes.

Kevin talks about it taking him 15-30 minutes a day to mark items as spam between his two accounts. Over the course of a year (365 days) he will have spent somewhere 90-182 hours dealing with spam. Ouch.

My situation isn’t nearly as bad, especially since I have only one inbox. I’d estimate daily 1-3 pieces of spam make it into my inbox per day. Since I normally keep my inbox completely empty, it doesn’t take much effort to mark the spam.

The spam making it through Google’s spam filter’s appears to be pretty standard and obvious stuff:

Currently my spam folder has 17 pieces of spam caught in the last 24 hours with 2 pieces missed. That’s a total of 19 pieces of spam with Google’s spam filter batting 88.24%. Compared to my way old hotmail account, that rocks.

Perhaps I shouldn’t bother marking spam? After all, I’m currently using 946 MB (12%) of your 7362 MB. Go ahead and spam me, my email can take it! Besides, what if I started taking up an interest in zoophilia and exotic “seex” positions?

Up next: Twitter spam.

PLEASE NOTE (2009-08-12): You probably do not want to use this method (though it’s great for learning). A much better solution is to use the gdata-objectivec-client. Example code on using that library can be found in one of my projects hosted on github.

I’ve been working on an iPhone app that uses one of Google’s APIs.  The following appears to work just fine in a non-jailbroke phone.

Creating the request

[objc]

NSURL *url = [NSURL URLWithString:@"https://www.google.com/accounts/ClientLogin"];

NSMutableURLRequest *loginRequest = [NSMutableURLRequest requestWithURL:url];

[loginRequest setHTTPMethod:@"POST"];</code>

//set headers

[loginRequest addValue:@"Content-Type" forHTTPHeaderField:@"application/x-www-form-urlencoded"];

[loginRequest addValue:@"application/x-www-form-urlencoded" forHTTPHeaderField:@"Content-Type"];

NSString *requestBody = [[NSString alloc]

initWithFormat:@"Email=%@&amp;Passwd=%@&amp;service=finance&amp;source=%@",

username, password, [NSString stringWithFormat:@"%@%d", @"ashlux-igFinance-1.0"]];

[loginRequest setHTTPBody:[requestBody dataUsingEncoding:NSASCIIStringEncoding]];

[/objc]

This part is fairly straight-forward. The service=finance should be changed to the Google service you are using.  Also ashlux-igFinance-1.0 should be changed to the format company-appname-version.

The default timeout interval for the request connection is 60 seconds.  To change this, use setTimeoutInterval:

[objc]

[loginRequest setTimeoutInterval:30]; // set timeout for 30 seconds

[loginRequest setTimeoutInterval:90]; // set timeout for 90 seconds

[/objc]

Sending the request

To send the request, I am sending a synchronous request (which will block) to Google:

[objc]

NSHTTPURLResponse *response = NULL;

NSData *responseData = [NSURLConnection sendSynchronousRequest:loginRequest returningResponse:&amp;response error:nil];

NSString *responseDataString = [[NSString alloc] initWithData:responseData encoding:NSASCIIStringEncoding];

NSLog(@"Response from Google: %@", responseDataString);

[/objc]

Objective-C does have asynchronous IO (non-blocking), but that’s for another time.  For most purposes, asynchronous is the way to go to avoid blocking the application.

Reading the response

For my purposes, I am storing the data in a struct called GoogleClientLogin to represent Google’s ClientLogin data (that’s simple enough, so I will not list it here).  For simplicity, I am not interpreting the response status beyond success (code=200) and failure (code=anything else).

[objc]

if ([response statusCode] == 200) {

NSLog(@"Login successful.");

GoogleClientLogin *aGoogleClientLogin = [GoogleClientLogin alloc];

aGoogleClientLogin.username = username;

aGoogleClientLogin.password = password;

NSString *authToken = [[responseDataString componentsSeparatedByString:@"Auth="] objectAtIndex:1];

NSLog(@"Google authToken=%@", authToken);

aGoogleClientLogin.authToken = authToken;

return [aGoogleClientLogin autorelease];

} else {

NSLog(@"Login failed.");

return nil;

}

[/objc]

That is more or less all there is to it. There is room for better error handling, but the effort would be better spent elsewhere on the applcation.

Next up, I’ve really need to figure out how to work in unit tests using Xcode.  My previous attempts at getting OCUnit working were full of fail special thanks to Apple’s out-of-date documentation.