One-time self-described “World’s Greatest Compressionist” Ben Waggoner posts a pointed question to the quicktime-api list:
http://www.apple.com/macosx/what-is-macosx/quicktime.html
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.
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.
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 dns-sd.org folks (at an @apple.com 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 @apple.com 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.
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.
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)
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.
Check out the updated Prags magazine rack for issue 2, with an overview of iPhone SDK development from yours truly.
