Archives for : March2009

Reading iPhone SDK Development on an iPhone

Great news from the Prags: you can now access ebooks you’ve purchased as PDFs on the iPhone or other mobile devices. Here’s a look, appropriately enough, at iPhone SDK Development:


Some nits will surely be picked: wide code lines are sometimes cut off, and the indexing picks up Marcel from the “with” line but not Bill and I from the “by” line. Still, I suspect this will be really appreciated by a lot of readers.

If it isn’t fixed, break it

iPhone SDK 3.0 has lots of lovely stuff… none of which I can currently discuss here, due to the NDA. At least now we know that the NDA will go away when this version gets a public release.

Suffice to say that there will be some significant new writing to be done before the iPhone SDK Development book is final. We’ll also have to be extra careful to watch for stuff we’ve written that’s either obsolete or has more attractive alternatives in 3.0. I could very well lose a whole chapter, all for the folly of making the book better. On the other hand, it’s a valuable opportunity to get the book right for 3.0, without fighting against copies already in the channel.

I’ve spent much of the day reworking the File I/O chapter. Again. This was the first one I wrote for the book, back around iPhone SDK beta 5 when there were painful IB bugs that required code workarounds that I never thought to remove from the book until much later, when people downloaded the example source and said “what the heck is this?”

The chapter’s always been a bit of a bugbear, in that it’s the first chapter that’s not about the UIKit GUI components, and instead uses the GUI to create a sample app that exercises the NSFileManager, input and output streams, etc. We’ve had a lot of pushback from readers, some of which I think comes from being pushed out of a comfort zone of Interface Builder “clicky draggy” and instead expecting the reader to know by now the basics of IB-Xcode interaction (e.g., if you intend to read a value from a text field, you’ll need to declare and connect an IBOutlet, etc.).

But on the other hand, I keep finding archaic code in the example, left over from those earliest betas of the SDK, some even pre-dating the availability of IB in the SDK, which is why there’s more creation of objects in code than we’d typically use today.

This was also before a lot of iPhone UI conventions got spelled out. Prior to today, you could select a row in the “directory contents” table and click a delete button. As it turns out, this is explicitly against the iPhone HIG, which says that table rows should not maintain selection state, and instead need to take an immediate action when tapped. So, in the next beta, the swipe gesture will delete rows, and since I don’t need to use the “row tapped” event to hold a selection for possible deletion, that can now become “navigate to subdirectory or file”, which I had assigned to an ugly accessory button.

So, not glamorous work, but it is making the chapter better. I’m also being more explicit about what the reader needs to write and where. The first drafts of this chapter were written without a lot of knowledge of its context, and integrating it with the rest of the book is going to take a little more time.

Next up, I’m not sure if I apply a similar overhaul to the database chapter (also highly minimal in the clicky-draggy department, but hasn’t gotten many complaints), start in on my AUGraph article, or start in on iPhone 3.0 APIs.

Battlestar Bingo

In advance of Friday night's finale of Battlestar Galactica, here's a little game to play to see if they tie up all the loose ends:


The board is written with JavaScript from 80-some possible items, so reload if you get a bad board. Tested on WebKit and Firefox. Thanks to Michael Ivey, Robert Cooper, and Michael Stemmle for trying out the prototype.

The iPhone recruiting comedy begins

Companies are staffing up iPhone projects, and as always happens with new technologies, they’re requiring levels of expertise that are highly implausible, if not downright impossible, for such new stuff.

Here’s a recent example:

1. 3-5 years previous experience developing application using Apple’s implementation of Objective C.
2. Provide at least two business applications that were developed for the Mac using Objective C.
3. At least 1 year experience development experience on the iPhone device.
4. Provide either a prototype or delivered iPhone resident application that displays data pulled from a remote Java class running on either WEBLogic or WebShere app server leveraging a backend Oracle DB.

Um, yeah. Thoughts on these points:

  1. What is this fixation that people have with Objective-C? The relevant skill-set that can be transferred from the Mac is Cocoa and the other essential frameworks. The syntax of Obj-C can be mastered in a day by any professional developer. If you’re looking for experience, then what takes time to learn is finding your way around the various frameworks, and developing a feel for the Cocoa way of doing things (design patterns like notification and KVC/KVO, etc.). The one key Obj-C thing you have to learn is reference-counting memory management, and the OS X developers can now opt out of that via garbage collection.

  2. Narrowing your focus to people who’ve delivered two shipping business apps for OS X probably gets you into the low thousands, if not hundreds, of eligible developers, world-wide. This one is just silly.

  3. The iPhone SDK was released March 6, 2008, meaning Friday is the first anniversary. Until then, the only people who can answer yes to this requirement are jailbreakers or liars.

  4. You’ve heard of web apps, right? They generally exchange data in HTML, XML, or JSON (or just with the HTTP request itself), so it generally doesn’t matter what language, app server, or database is running on the backend. In fact, I think most architects today would consider it a mistake for a client to know, care, or depend on what was actually running on the backend.

So, um, good luck with the recruiting, guys. If wishes were horses…

Audio latency < frame rate

So here’s what I’m working on at the moment, from an article for mystery client who I hope to reveal soon:


Yep, if latency is buffer duration + inherent hardware latency, then this app needs just 29 ms to get the last sample in its buffer out the headphones or speaker. And really not that hard once you reacquaint your mind with old fashioned C.

A world of difference from the awful time I had on Swing Hacks trying to use, explain, and justify, which has a push metaphor, requiring you shove samples into an opaque buffer whose size is unknown and unknowable. To say nothing of Java Sound’s no-op’ed DataLine.getLevel(). Analogy: Core Audio is The Who. Java Sound is The Archies.

Next up, working through the errata on iPhone SDK Development, now that we have a first full draft in tech review.