Archives for : August2009

What’s New, Blue Q?

One-time self-described “World’s Greatest Compressionist” Ben Waggoner posts a pointed question to the quicktime-api list:

What I’d like to know is if QuickTime X is going to be available for Windows and older versions of Mac OS X.

It’s an important issue, because despite iTunes’ insistence on installing QuickTime on Windows, the future of that product seems completely unknown. For years, every question I’ve seen about the future of QuickTime on Windows has been met with absolute silence from Apple. Yeah, I know, “Apple does not comment on unannounced products,” and all… Still, Apple has left this technology in limbo for a remarkably long time. I recall asking ADC reps about QuickTime for Windows back at Leopard Tech Day Atlanta in 2006, as I was considering calling it from Java with JNI, and (as previously noted), I got no reply at all. And every other public question I’ve seen about the future of QuickTime on Windows has gone similarly unanswered, for years.

Smell that? That’s the scent of Abandoned Code Rot. We got that from QuickTime for Java for a few years before they managed to finally deprecate it (though they apparently haven’t gotten the message out).

It wouldn’t be too surprising to see QT for Windows fall by the wayside… Apple probably cares more about the popularity of its favorite formats and codecs (AAC and H.264) than of the QuickTime APIs and QuickTime’s interactive features like Wired Sprites that have been clearly and unequivocally beaten by Flash.

But if that’s true of Windows, is it also true on the Mac? QuickTime developers are right to be a little worried. The old C-based QuickTime API remains a 32-bit only option, intended to be replaced by the Objective-C QTKit. But in the four years since its introduction in Tiger, QTKit has only taken on part of the capabilities of the old QuickTime API. With Leopard, you could finally do capture and some significant editing (e.g., inserting segments at the movie or track levels), but raw sample level data was unavailable for any track type other than video, and some of the more interesting track types (like effects and especially tweens, useful for fading an audio track’s volume between specific times) are effectively useless in QTKit.

With Snow Leopard, the big news isn’t a more capable QTKit API, it’s QuickTime X. And as Apple’s QuickTime X page points out, QTX is all about a highly-optimized playback path (using decode hardware if available) and polished presentation. Great news if you’re playing 1080p movies on your computer or living room PC, not so much if you want to edit them: if you want to edit anything, you’re back in the old 32-bit QuickTime (and the code is probably still written in C against the old APIs, given QTKit’s numerous limitations). You don’t see a 64-bit Final Cut Pro, now do you? (BTW, here’s a nice blog on that topic.)

When you all install Snow Leopard tomorrow and run the QTX-based QuickTime Player, you’ll immediately understand why the $30 QuickTime Pro (which bought you editing and exporting from the Player app and the plug-in) is gone. Follow up in the comments tomorrow (after the NDA drops) and we’ll discuss further.

If I were starting a major new multimedia project that wasn’t solely playback-based — imagine, say, a podcast studio that would combine the editing, exporting, and publishing tasks that you might currently perform with Garage Band, iTunes, and FTP — I would be very confused as to which technology to adopt. QuickTime’s cross-platform story seems to be finished (QTJ deprecated, QTW rotting away), and everything we hear on the Mac side is about playback. Would it be safer to assume that QuickTime doesn’t have a future as a media creation framework, and drop down to the engine level (Core Audio and Core Video)? And if not QuickTime… then what?

Oh, and as for the first question from the quicktime-api thread:

… How about Apple throwing us a bone as to what QuickTime X will offer those of us that use QT and QTSS?

From what I can tell, Apple has all but ditched QTSS in favor of HTTP Live Streaming, supported by QuickTime X and iPhone 3.0.

Playing with KVC

Nothing major, I was just looking at some different approaches to setting contents of nib-loaded table cells that may need to be more dynamic than usual. I caught myself playing with key-value coding and thought that the following three lines – all of which do the same thing – were kind of neat:

cell.textLabel.textColor = [UIColor greenColor];
[cell.textLabel setValue: [UIColor greenColor] forKeyPath: @"textColor"];
[cell setValue: [UIColor greenColor] forKeyPath: @"textLabel.textColor"];

All you have to do to participate in KVC is to use properties, or follow a convention for naming getters and setters.

I’m looking at doing some custom tables (see my impromptu screencast on flippable cells) and was wondering about approaches to putting different kinds of cells different table instances. Seems like KVC would be one technique to get at the labels and other subviews of variant UITableViewCell subclasses, without having to know the actual class at compile time. Guess we’ll find out if it works nicely.

A shelf tour

After last week’s crunch, closing the last of the errata and our own to-dos, we have officially sent iPhone SDK Development to production, meaning it will now get a second copy-edit, typesetting, printing, binding, and shipping to your anxious hands.

A note of thanks is in order to the beta-program purchasers and the thousands of errata they filed, along with over 500 forum discussions on the book. No getting anything past this group, that’s for sure.

Well, maybe one little thing. With the Snow Leopard release date now set, it looks like Apple engineers have a chance to reply to e-mail from several months ago. Last night, I heard back from the folks (at an address) about my request back in June to reserve a Bonjour service type for the Game Kit example in the book. The bad news is, I included an illegal character in my service name, so I had to change it from amiphd_p2p to amiphd-p2p, which is now part of the public list of DNS SRV (RFC 2782) Service Types. And the only reason that’s bad is that the book still has the name with the underscore, and I’m currently locked out of the book during production.

It’s a minor point, and it will get fixed, it’s just silly-bad timing, getting a reply to a two-month-old e-mail just a day after we wrapped the book.

Another interesting e-mail has to do with the Clang Static Analyzer that we cover in the performance chapter, but that remains NDA for now. Anyways, they’ll have their own updates in due course, so watch their page.

Related point: I went to the Barnes & Noble on 28th Street for the first time in ages today, and drifted by the computer book section. It’s probably the biggest in Grand Rapids, for what that’s worth. Computer book sections are shrinking everywhere, particularly the programming sections, for a number of reasons: anything nichey is a non-starter at retail and is basically only available via Amazon and the like, programmers are eagerly jumping into eBooks (or bundles where you get a PDF now and the paper book when it’s ready), some programmers prefer the immediacy of blogs and other informal sources to stuffy books, and of course nearly any computer eBook of any significance is on bitTorrent (including ours, despite the fact that the unauthorized PDFs all clearly identify the reader who chose to post his or her copy). All of which goes to explain why your local retailer has less reason to stock computer books when they can make more money off political screeds and trifling fiction. And, as I discussed a few weeks back, why you’re going to continue to see fewer and fewer programming books going forward.

Still, the iPhone SDK is such a hot topic that even all this friction can’t stop it from being a popular topic with readers and authors alike. There were at least four other iPhone programming books on the shelves, and I took a first peek at several of them today. Note of explanation here: when writing a book, I never look at anything that could be considered a “competing” book. It’s my own mental firewall that ensures that my work is my own, and that I don’t lift ideas from fellow authors. That said, I do read the official docs, both to learn things myself and to make sure that the book I’m writing goes beyond what you can get for free. There’s no value for the reader (or the writer) if the book is just a paraphrase of Apple’s programming guides.

I think the only one on the shelves today that is officially updated for iPhone SDK 3.0 is Dave Mark’s Beginning iPhone 3 Development book, which features significant coverage of Core Data, probably the most significant of the new features in iPhone SDK 3.0. Of the older titles covering iPhone 2.x, I saw Erica Sadun’s, Jonathan Zdziarski’s, Neal Goldstein’s and Christopher Allen and Shannon Appelcline’s books.

They’re probably all worth a deeper read, though a glance through them and a mental comparison to my own project of the last year shows some similarities and differences. I’m sure all of us are grateful for the ease of getting screenshots from the simulator, as all the titles are rich with illustrations. Nearly all of them cover OpenGL, which ours actually doesn’t, I think because Bill thought that readers would be better served by studying OpenGL on its own (and that there isn’t enough unique about its iPhone implementation… as opposed to say, SQLite, which I put in the book not so much for the SQL or even the C API as for the strategies of managing the database files within an iPhone context: creating them with your Mac’s sqlite3 interactive shell, putting them in a bundle for deployment and backup, etc.). On the other hand, I think ours is the only book to talk about debugging and the various performance tools (Shark, Instruments, and the third-party Clang Static Analyzer). Unsurprisingly, given my inclinations, it looks like we hit media a lot harder than our peers. Counting the new-for-3.0 “Music Library Integration” chapter, we ended up with four media chapters, totaling nearly 75 pages. And that’s after cutting the too-hard-for-now Audio Streaming chapter.

It looks like all the other authors assumed a pre-requisite level equivalent to ours: know a curly-brace language, preferably C, and we’ll cover Objective-C as we go. We’ve had a few scripting-language converts (Flash/ActionScript people, it seems) on our forums who have a hill to climb with the latent subtle C-isms, mostly the memory stuff, and I wonder if our colleagues have had similar experiences with their audiences. C knowledge is a strange thing: all us old folks think it’s a lingua franca, yet I think we all know that younger developers no longer learn it as a matter of course, and may not be particularly eager to do so.

Anyways, I imagine everyone else is rushing out their 3.0 updates too, so it’ll be interesting to see what new features get covered, and what our readers still want from us in future versions or more advanced titles.

Travel Hazards

Sorry for the lack of updates. I’m traveling with family in San Diego, with the occasional futile one-day trip up to Disneyland (it may be the Happiest Place on Earth, but it’s no match for Autism Challenge Boy).

Anyways, had to get this off my chest. The Grand Rapids airport (GRR) has free wi-fi. Which is usually a good thing. They even have a special greeting page for iPhone users:

This page then changes to a “click to continue” page:

So you click the link to continue on to the original page you requested. Except that you end up back here:

Yep, the whole thing is a goddamn infinite loop of two advertising nag pages. And with no way to spoof your user-agent on the iPhone, there’s no way to get around it.

And it was this way when I departed from GRR for WWDC back in June.

And when we went down to Florida in February. On that occasion, I sent an e-mail to the airport asking them to fix it, and got a brush-off “yeah, yeah, you don’t understand our awesome technology, little boy” reply.

Anyways, the “FlyGRR” network is useless, and if you’ve had the misfortune to connect to it, there’s only one sensible course of action:

It’s annoying, but at least there’s no injury involved. That was reserved for our connection in Chicago. Ever heard those urban legends that escalators can rip kids’ Crocs, and sometimes some toes, right off their feet? Turns out it’s true. 4-year-old daughter Quinn was going up an escalator with my wife on the United concourse when her right Croc got caught. This is what it looked like after cleaning it (and her) up in the bathroom:

Notice that there’s a tear coming off one of the holes in the middle. Quinn describes the incident as “the escalator tried to take my Croc”. I still don’t know WTF happened, but I’m glad she’s not injured, and I guess I have to take the legend of Croc-eating escalators a little more seriously.

Screencast Experiment: FlippyCell

I was experimenting with UITableViewCells late last week and wanted to show off a couple things I thought were interesting, and decided to do so in the form of a screencast.

Click to view flippy-view.mp4 (MPEG-4: H.264/AAC, TRT: 15:35)

Click to view flippy-view.mp4 (MPEG-4: H.264/AAC, TRT: 15:35)

The demo is an experiment I did to get UITableViewCells to “flip over”, by doing a transition with Core Animation. I ended up doing a few nib-loading tricks that are worth remembering, and wanted to share. So here’s the FlippyTableCellThrowaway Xcode project as a .zip file, MIT licensed (seriously, do what you want with it, don’t even bother with attribution, just don’t be a dick by passing it off as your own work).

This was also an experiment for me in terms of shooting and narrating a completely off-the-cuff, no-edits screencast. I haven’t even bought proper screencast software, so you can see the iShow U watermark throughout (and I only chose iShow U because Screenflow‘s watermark is far more prominent).

Anyways, hope it doesn’t suck. This was a total hack job in terms of code (haven’t even removed all the log messages and commented-out mistakes) and screencasting, so buyer beware.

PragPub Issue 2 is out

Check out the updated Prags magazine rack for issue 2, with an overview of iPhone SDK development from yours truly.

What Are Words Worth?

I was listening to a podcast talk from Mises University 2009 the other night called “Intellectual Property and Libertarianism”, in which speaker Stephan Kinsella made the usual Slashdotty-type case against IP from a libertarian perspective. This was novel for me, perhaps because libertarians tend to be very defensive of property rights, such as Ayn Rand’s assertion of IP as a right to the products of a person’s own mind.

Kinsella rejects Rand explicitly, saying her case offers little more than deification of the creator. His counter-argument is interesting: IP is inconsistent with property rights because it violates the rights of others to use their property. To wit, if I own a typewriter and a stack of paper, or a CD burner and some blank discs, then those should be mine to do with as I see fit. But because of copyright, I can’t use the typewriter to transcribe a book, or to use the burner to copy a CD, even if I’ve bought original copies of the hypothetical book and CD. IP asserts a partial ownership — enough to say “you can’t do that” — over this other property I own. That, according to Kinsella’s argument, is inconsistent and therefore invalid.

Interesting, and tricky, and I don’t quite know what to make of it.

It’s important because, of course, my income is highly dependent on the idea of IP. If I couldn’t charge for copies of iPhone SDK Development, I probably wouldn’t have spent hundreds (possibly thousands?) of hours over the last year and a half co-writing it. If I couldn’t charge for apps on the App Store, would I write them?

The counter-argument comes from the open-source crowd, who say to give away your content (which, by the earlier argument, you couldn’t own anyways), and make your money some other way. This is really appealing when you’re working in some field where the value isn’t in the content, per se. It’s easy to open-source your stuff when you make your real money using it for consulting projects, or running a service. It’s a lot harder to see a model that supports development of, say, productivity applications, where the value in the software is in what it lets the user do with their own data. Give that away and where’s the ancillary revenue stream that would fund future development? Tip jar? Selling t-shirts? Maybe this is why Linux has so few productivity apps of any note (a few mediocre-to-bad knockoffs of Office and Quicken and such, but you’ll likely never see something like Final Cut Pro on Linux).

Bringing it back to writing, there are economic models that can keep a tech writer going. One is that the owners of a technology can commission writing about a topic to spur interest: I’ve made more writing three articles on Core Audio for [redacted] than I made on my entire QuickTime for Java book. I think this is going to be an even bigger deal going forward, as books and feature articles become one more thing that platform owners will have to pay for themselves in order to get mindshare (much the same way that platform owners already provide technical documentation and tools… note that there’s much less of a market for commercial IDEs now that the Windows, Mac, iPhone, and Java platforms all have a free-as-in-beer IDE provided by the platform owners).

Another possibility is that the real value of writing blogs, articles, and books gets your name out there for consulting work, although in my experience, it’s hard to shake the impression that you’re “just” a writer. I just finished a month-long consulting/programming engagement and am working on a new app for the App Store, yet I’m still clearly far better known for my writing than anything else.

As for the IP of books and being able to charge for them, the existence of .torrents of pretty much any available eBook may put that issue to rest quickly enough. On the one hand, I think it’s absurd that developers won’t pay what amounts to about 20 minutes of the developer salary they’ll be able to charge once they’ve mastered its techniques. But maybe some/most readers would kick in some kind of payment if it were completely on a tip jar system? Enough to keep a writer able to pay his or her bills? Probably only on the most popular topics.

And that’s why you shouldn’t expect me to ever propose, no less actually write, the big Mac/iPhone media APIs (QTKit, Core Audio, etc.) book that I’ve kicked around for a few years. Something that nichey, combined with the rapidly falling price that readers are willing to pay for content, makes it effectively unviable.