You write a prompt, hit enter, and watch the console light up green. Code pours out. It feels like magic. Then you try to maintain the thing a week later, and you realize your shiny new AI agent just built a leaking bucket.
It's been a while since I wrote about what I'm doing, but nothing much has changed: I'm working with the iPhone SDK making different applications. Today I'd like to demo the application that made me start working with the iPhone: DashBoard. I first got interested with dashboards when I tried to make something userfriendly with Performance Point and found IMA's dashboard. Now I've created a simple, easily customizable dashboard for the iPhone. Because of Apple's NDA I cannot release it, but I believe I can show it to you, running on the simulator:
Debugging Autorelease is a great wiki entry at CocoaDev. EXC_BAD_ACCESS, meaning accessing an object you've already released (most likely) or have not yet instantiated (it happens) isn't that fun to debug. Luckily, the NSZombie environment variable works when developing for iPhone as well, and I could find the error that had cost me most of my day. Yay! 
Other good resources for debugging are Debugging Techniques and Mac OS X Debugging Magic
The mac world is high on expectations because of what is apparently a shortage of iPhones. New version coming up soon? Yes, probably. People hope for a 3G version. I hope for one too. I expect it to be announced in June and available end August. People think of a 32gb version. Sounds logical. But didn't people notice Intel's announcement of their Atom processor? Here's ZDNet's take on it. I would expect this to mean that an iPhone based on this architecture would be launched, perhaps silently even. Just a bit more horse power, very fitting for iPhone OS 2.0. Perhaps with a 32gb option. But still EDGE, no 3G. Then a 32gb version with 3G could be announced in June and become widely available in august.
It's all over the news: due to budget problems, NASA puts Spirit into hibernation and cuts back on the activity for Opportunity. Where do I sign the protest list?!
Being fairly new to Cocoa I enjoyed reading O'Reilly's MacDevCenter's article on exception handling with Cocoa.
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 do this otherwise as atos(1) isn't included with the default OS X system either. 
But I would really, really like to include stack traces with bugreports from beta testers.
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 is a lot better than it just influencing that screen.
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.
[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
{
}
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: