One thing I love about Java development is the ease of finding bugs through stack traces. Unfortunately, it doesn't seem that Cocoa likes being so verbose about it, it prefers just giving memory addresses to the function. CocoaDev has a nice article about how to add this that's based on Apple's documentation, but it requires /usr/bin/atos that I cannot find in the iPhone SDK. That doesn't mean it's not installed, but at this time I have no way of knowing that it is. I have no idea how I should let people beta-test my products and sending automatically back intelligent bug reports without this tool. Ok, I have no idea on how Apple plans to allow for betatesting applications if the AppStore is the only application distribution method, and I have no idea how people ...

[class-dump][1] is a great tool for getting information about how private frameworks work that you may want to use. For example, iPhotoAccess.framework gave among other classes the following:
`
@interface Base64 : NSObject
{
}

+ (id)stringForBase64:(id)fp8;
+ (id)base64ForString:(id)fp8;

@end
` [1]: http://www.codethecode.com/projects/class-dump/

According to iPhone Atlas, Google has pushed out a new release of its GData Objective-C Client Library that can be used with the iPhone SDK. Yay for Google! Check it out! For my last job I used Google Spreadsheets and Google Documents quite a bit, and it's great being able to integrate it. Making a little word processor with synchronization to GDocs should be fairly trivial now.

My work with the iPhone SDK continues, working on three clients to our backend services at the moment. I'm very much looking forward to blogging about this as it's cleared at work. But as you probably have noticed from my posts, working locally and synchronizing with the back-end is what I believe most iPhone applications are about. Do quick and stuff you need to remember on the iPhone, work out the details from your computer, keep everything in sync. That's why I'm excited about Google's data integration. That's why I'm excited about integrating SQLite. That's why I spend a lot of time working with SOAP integration. And of course, it's all good fun. I'm tempted to say that working with a back-end is a lot easier than doing everything local. At least the satisfaction of seeing the work you do on the little screen influencing the real world ...

After asking on the MacRumors forums I was pointed back to FMDB that I had looked at a couple of days ago. FMDB is a Cocoa wrapper for SQLite3. I had a look at it, and after my initial difficulties, I found that I was trying a way to complicated way to use it for my iPhone applications. To add FMDB, simply do the following:

• in XCode in your project window, rightclick your "Classes" and Add -> "New Group", call it FMDB
• drag the files from src in the FMDB package into the new group
• Rightclick Frameworks, Add -> "Existing frameworks", select /Developer/Platforms/Aspen.platform/Developer/SDKs/Aspen1.2.sdk/usr/lib/libsqlite3.dylib ...