Sometimes there is no time to focus on just one or two things. No, sometimes things get busy and between day jobs, and night jobs, and family, and all those other obligations we have in our lives, there is time only to touch on a few things briefly. That’s what my development life has been like lately, moving from project to project to project. Read on for a cornucopia of stuff…

Project X Update

It’s been some time since I last (first?) wrote about Project X. The project continues, but at a slowed pace due to other demands. However, I can say that work is progressing and milestones are being achieved.

The most recent work has been around finding a “first screen” that is compelling and inviting, but not too difficult to deal with from an implementation standpoint for both iPhone and iPad as well as from a user interaction standpoint.

The “first screen” is the launching point for several versions of the app. I played around with several designs, implementing a couple, but I think I’ve finally settled on the design that I’ll run with. So, that is progress. I am feeling like the framework and game mechanics are coming together nicely and I will be able to move on to some of the more interesting “new ground” soon (like Game Center integration.)

Client Work

Some new client work has begun (a “night job”) and since it’s a paying gig, it is consuming a lot of my available spare time. The client is, at this point, a long-term client who has a pipeline of project work that ebbs and flows. Right now it’s flowing.

The project is a simple app, based on some previous work, for a client of my client. It’s a fun little app, made more so because we were able to put certain restrictions on the app like “iOS5+” and on the v1.0 feature set.

So far progress has been relatively swift; the basic app is working. What remains are some UI details and some edge cases. When the app is released, I’ll be sure to post about it.

Technical Tidbit

Twice in one day this week I saw people asking how to run an app in the simulator and debug it from the command line. That is to say, how to debug an app without using Xcode as the debugger. I am not sure, really, why you’d want to do this, but it turns out it is possible and very easy to do.

There are (at least) two debuggers available on Mac OS: gdb and lldb. Both are available within Xcode, and both are available at the command line.

To debug an app running in the simulator, you first have to get the app into the simulator’s Springboard. One way to do that, obviously, is to run the app via Xcode in the simulator! So, do that, and then stop the Xcode debugger, but leave the simulator running.

Next launch Terminal.app, and at the command line type:

[code]
% gdb
[/code]

There will be some output from gdb (you can ignore it) followed by a prompt, at which you type the following command:

[code]
(gdb) attach –waitfor ‘Name Of Your App’
[/code]

Replace ‘Name Of Your App’ with whatever the name of the process will be for your running app. Remember, when you run apps “in the simulator”, they are just Mac OS programs running on your Mac in a process with a name. In this case, it’s the name of your app.

Next, launch your app in the simulator by clicking its icon. The app will start, but you won’t see much since gdb will attach to the process immediately, even before main() is invoked in your app. This is actually a good thing because you can set breakpoints now before the app actually starts running, and then simply start the app:

[code]
(gdb) b viewDidLoad // for example…
… // You’ll see all the viewDidLoad entry points listed
(gdb) continue // go!
[/code]

When you hit a breakpoint, you’ll have command line control in the debugger. And gdb at this point works just like it does within Xcode. (Note that you can type ^C within gdb to force a break wherever your app happens to be, too.)

I guess the reason to debug from the command line is that you don’t have Xcode “in the way” of your debugging session. But honestly, I’ve never felt like Xcode was in my way for debugging (except when Xcode gets “confused” and must be restarted, but that’s a story for another time.)

The procedure to use lldb form the command line is similar:

[code]
% lldb
(lldb) process attach -n ‘Name Of Your App’
<launch your app in the simulator>
(lldb) continue
[/code]

Learning Core Audio

This week the book Learning Core Audio: A Hands-On Guide to Audio Programming for Mac and iOS by Chris Adamson & Kevin Avila became available. I mention it because it is probably the most complete reference you will find on Core Audio for Mac OS and iOS. I had the privilege to read it over the last year as a technical reviewer. (I’m even listed on the masthead as such!) The care and attention to detail with which this tome has been crafted is evident in every chapter and every example. The authors worked very hard to make the book accurate and useful, and I think they succeeded. If you have any interest in Core Audio I recommend this book highly.