Tuesday, August 17, 2010

Dealing With Dashcode, Part 4: Dashcode and Debugging

UPDATE: As Todd points out in a comment, the bug described here has been fixed in 3.2.4.  That's now out of beta, and registered developers can download it from Apple.

(This is a continuation of a previous post. You may want to read the first post in this series for an overview of the architecture.)

The last problem I'm blogging about is actually the first one that I encountered. It's also what first inspired me to write this "Dealing With Dashcode" series of posts.

Early on in my development process, I made sure that I had the latest XCode installed (3.2.3), which is the iOS 4 development environment; my app is targeting iOS 4 on iPhone 3GS and 4.  The iOS SDK includes the iPhone Simulator, with environments for iOS 3.2 on the iPad, and iOS 4 on the iPhone 3GS and iPhone 4.

Dashcode comes with a quite handy JavaScript debugger.  Since Mobile Safari's built-in developer support is fairly scant (you can globally turn on and off console logging), having a JavaScript debugger is really handy.  The JavaScript debugger works against Mobile Safari in the simulator: when you're running your program in the iPhone Simulator, you can use breakpoints, inspection, single-stepping, etc. from within Dashcode's debugger.  Nice, huh?  Too bad it doesn't work.

Here's what I've been able to work out.  Dashcode implements this debugger by loading an extra framework into Mobile Safari when it launches.  When you click the "Run" button, Dashcode launches Mobile Safari with some extra arguments to load a framework called CayenneClientDebugger (which is within the Dashcode executable).  It looks like Mobile Safari (as well as the Browser Simulator that's part of Dashcode's Safari targeting) has hooks to load this framework for some debugging usage.  The debugger UI that's built into Dashcode communicates with the debugger backend loaded in Mobile Safari.

(By the way: I looked online to see if I could find any references to this Cayenne.  There's an Apache project named Cayenne, but it seems unrelated.  I suspect that Cayenne was the internal codename for Dashcode; it looks like the bulk of Dashcode is implemented in a framework called CYKit.)

Now, here's the catch.  iOS 4 uses a different ABI than 3.x did.  It looks like the CayenneClientDebugger is built for the old version.  Mobile Safari refuses to load it, so instead of a debugger, all you get is a message in system.log.

I tried to cherry-pick a few bits of XCode from a backup I had from before I upgraded it.  I tried copying iPhoneSimulator3.0.sdk into the current installation, and although the iPhone Simulator would display the 3.0 version in its Version menu, if I tried to actually select it, then the Simulator would crash.  I tried a few other combinations of replacing the Simulator, CayenneClientDebugger, and even all of Dashcode, but couldn't get anything really going.  I probably could back out the entire XCode installation, but that's a bit far.

As it was, I never did solve this problem.  I just made a lot of use of console.log for debugging purposes.  If I needed something more than I could get that way, then I'd use Safari (the OS X one); I could load my webpage there and use Safari's built-in development tools.  The most signifiant bit of UI I was using for this app (StackLayout; it's essentially a nested list that you navigate one level at a time) doesn't actually work in Safari — only Mobile Safari — but I could still test little bits in some ways.  It was enough for me to finish coding.

I haven't looked into the 4.1 SDK yet (as of this writing it's in beta and has limited availability); I hope that Apple's fixed this problem.  Not having access to a debugger makes Mobile Safari development a bit tricky.

By the way: there are a few options out there.  The best of these seems to be "Firebug for iPhone".  Don't get your hopes up, though: it's not Firebug (the must-have development tool for Firefox).  It's not even close.  Firebug for iPhone mostly just relays console messages to your server, and lets you send commands to the browser.  While this is very useful, it's still not a substitute for a full JavaScript debugger.  (I considered writing something similar, using AJAX to relay messages between my code and a program running on my server.)

IBM has an article on using Aptana (a webapp development system for Eclipse) while developing iPhone web apps.  It's entitled "Debug iPhone Web applications with Eclipse", but in truth, Aptana doesn't support the iPhone for debugging.  Instead, the article recommends you use Firefox with Aptana to debug your application.  Uh... no thanks.  WebKit and Gecko are different enough that, if I'm developing an iPhone-specific application, I'll want to do my development with Mobile Safari.

Neither of these was really worth the effort of learning; the app in question is simple enough that console.log does everything I needed.  But I do hope that Apple has fixed this problem in the newest Dashcode.

2 comments:

sudmars said...

Good to see that other peoples have the bug. I have left a post on apple forum where a message without solution allready mention this bug.
I want to play with touch events so Safari does not do the job. Maybe with the coming of the magic track pad it does but I don't have this device.

Todd Fincannon said...

This bug is fixed in Xcode 3.2.4. As of 1 Sep 2010, this is still in beta, so you need an iPhone Developer membership to get it.