Archives for : July2008

The Mob is Not Helping

Sigh, the whole “iPhone SDK still under NDA” problem has gone from annoyance to clusterfsck with the participation of the online mob.

It wasn’t encouraging to see that the first followup to PragDave’s blog was a bit of F/OSS trollery:

Sounds like poetic justice if you ask me. This is what you get with a locked-down platform.

That theme is repeated in the discussion to the Slashdot story, Inside Apple’s iPhone SDK Gag Order (see also the InfoWorld blog it’s based on) replete with lazy cynicism and nefarious skullduggery! about crazy dictator Steve Jobs, Apple’s “monopoly” and how they’re no different than Microsoft, and how the iPhone is junk anyways and how anyone with any sense will use a totally open platform. To top it off, there’s now an obscenely named site to collect bile and rancor related to the continued NDA status of the iPhone SDK.

Having written almost 100 pages of an iPhone book, all of which is for naught as long as the NDA is in place, I would like to make a request of the mob:

Would you all please shut the hell up?

First off, let’s apply Adamson’s Efficacy Rule: all actions should be purposeful and reasonably expected to produce the desired results, with forseeable side-effects not being worse than leaving the original goal unmet. Does anyone seriously think a bunch of geeks talking shit about Steve Jobs in a Slashdot forum is going to change Apple’s mind right now? Can anyone point to the last time the company was successfully petitioned for a redress of grievances? If you really think that Apple doesn’t care what you think — and you’re right, they don’t — then why are you bothering to express yourselves this way?

Secondly, what realistically is the alternative? The F/OSS trolls would have us believe that non-proprietary mobile software stacks are just as good as the iPhone, but this is laugh-out-loud ridiculous. In more than a decade, one thing that the open source movement has demonstrably proven, is that while it’s great at writing software that interfaces with other software (servers, libraries, etc.), it is absolutely incapable of developing end-user applications that anyone in their right mind would want to use. I’m not talking about the “eye candy” cliche that’s thrown at Apple as an insult; I’m talking about the fact that last time I used GNOME as my day-by-day desktop, I found 30 ways to change the theme and not one to set the clock. There’s never going to be a decent open-source software stack for a phone because nobody who cares about writing software for use by humans and is talented at it is going to contribute to such an effort. F/OSS has been a complete failure on the desktop, and it will be a complete failure on the small device, for exactly the same reasons.

Granted, I think that insisting on an NDA on software that is no longer designated as beta, and has been downloaded by over a quarter-million developers is foolish. They can’t realistically enforce such a thing — some of the best information I’ve found, like a crucial tip on using custom table cells created in Interface Builder, is hosted on Apple’s own forums — and it only serves to hurt the overall quality of iPhone apps when developers can’t share experience, tips, wisdom, and lessons learned. And it’s because of that utter untenability that this situation will change, and soon. At least from what’s publicly known about the platform, there’s little point to continuing the NDA at this point. In time, I think they’ll work through whatever problems they have and set things loose.

In the meantime, asserting that evil Steve Jobs will “demand that people conform to his world view, and demand that the people working for him force their customers to conform to his world view” is just goddamned stupid. And won’t make my life any easier anytime soon.

Bonjour, Bonjour

Short note before hauling the family over to Michigan’s Adventure, en route to Torch Lake. I wrote the last example for the networking chapter on Monday, a simple exercise in service browsing with Bonjour (né Rendezvous, aka ZeroConf). I was already a fan of highly-dynamic, service-discovery-based networking from Jini many years ago. Bonjour is much less ambitious than Jini, whose money shot is in providing appropriate executables to callers at runtime, but in many ways, Bonjour is particularly useful for network services we already have (a remarkably large number of which are already defined).

The thing that surprised me is that there’s a point at which Bonjour ends, namely, once you’ve discovered and resolved a service. After this, you have a host, a port, and some optional metadata, and it’s up to you as the caller to begin a protocol-specific conversation with the service on that port. In theory, that sounds like you’re being asked to open up sockets and go into low-level BSD mode (or CFNetwork, at least), but not necessarily: the service description could indicate that you use HTTP on some non-80 port, for which Cocoa provides convenience classes. In this case, you’d basically have a LAN webservice, one which would be very easy to write both ends of (I’m tempted to do a quick one-off Bonjour chat app, in which the peers post messages to each other with HTTP POSTs).

For the book example, in order to keep the focus on the service discovery and not the socketry, Daniel suggested I just browse the Bonjour-exposed Apache web servers on local Macs, and load their first pages into an iPhone web view. This turned out to be pretty simple and very clear in showing the key Bonjour steps. I think this is going to be a nice chapter when I finish writing the last section.

Next… not sure, but for a break from APIs, I may do performance and debugging (and probably app-signing to put your app on the device, since that’s currently broken on the laptop and I’ll therefore have to go through all those steps for myself again anyways).

Prags’ open call for iPhone NDA roadblock-clearing

No progress to report on getting the book’s beta out, but Dave Thomas of the Pragmatic Programmers has posted a call for help on unblocking the iPhone NDA holdup. He also links to our iPhone book’s home page. There’s also a discussion forum for the book, which will be much more significant and active when there’s publicly-available content to go with it.

Production Philosophies: Wipeout versus Banzuke/Sasuke/Kunoichi

Maybe it’s the schooling talking, but I believe that the difference between many TV shows is the implicit philosophies of the producers. Intentionally or not, programs say things, and mean things, expressing values that are implicit in what goes into the show and what’s left out. You don’t have to look at shows that are explicit about their beliefs — the cynicism of Battlestar Galactica, the quasi-libertarianism of South Park, the Zen of Fullmetal Alchemist, the individualism of The Prisoner, the “stop bullshittng us” agenda of The Daily Show, etc. — since even simple shows speak volumes about the belief systems of their producers and audience.

Case in point: ABC’s Wipeout versus the Japanese obstacle course shows that inspired it, notably Kinniku Banzuke, Sasuke, and Kunoichi. Superficially, they’re highly similar: contestants race through obstacle courses of absurd difficulty, with mishaps sending contestants tumbling to a pool of mud or water below.

But take a deeper look and they could not be more different.

Wipeout, the American show, pits the contestants against each other for a $50,000 prize. For any contestant to win, all the others must fail. In the various Monster9-produced shows, the contestants battle only the course itself. In theory, they could all complete it and win, though more typically, all the contestants fail. There is no mention of a monetary prize for the winners of the Japanese shows. Instead, the honor of winning is stressed: the concept of the “Kinniku Banzuke” (literally, “Muscle Ranking”… the show got the exotic title “Unbeatable Banzuke” when dubbed for Western audiences) is that of an eternal honor roll of the champions who have beaten the various challenges. When someone’s name is “added to the Banzuke”, the previous winners names and pictures are also shown. In Sasuke, every episode reminds of us the only two people in the course of 20 competitions to complete the entire course, years after their successes. By contrast, Wipeout wipes its memory clean every episode: previous contestants are never heard from again.

A fall from any obstacle in the Monster9 shows results in immediate disqualification. The point of their difficulty is to enhance the esteem of those few who can clear them. In a typical Sasuke competition, stage one will eliminate 90 of the 100 contestants, with stage two whittling out several more of the remaining 10. Falling on Wipeout is not grounds for disqualification. Indeed, it’s the very point: many of the obstacles are clearly impossible to navigate cleanly, and the appeal of the show is watching people, well, wipe out.

It probably sounds like I’m making the case that the Japanese shows are better, and indeed, I enjoy them more. But I think for what each is, they’ve made exactly the right decisions. Sasuke appears just twice a year, with its female spinoff Kunoichi appearing just once annually. They are events, and are produced as such: catching us up with what’s going on in the lives of fan-favorite contestants, reminding us of prior competitions, etc., helps to build the sense of time and importance that the event requires. This is exactly the magic that Who Wants To Be A Millionaire originally had as a sweeps-only weapon, until ABC foolishly overexposed it as a thrice-a-week series that sapped the uniqueness of the event (it got to be be pretty silly to be talking about “night 73 of Who Wants To Be A Millionaire”).

Wipeout, on the other hand, isn’t meant to last. It is not an event, it is a novelty, a diversion. It’s something you happen across after a day of summertime activity, or maybe before heading out for a warm summer night. The producers wouldn’t expect, or even want, viewers to tune in every week, and the only reason you’d ever TiVo and keep the entire run of the series would be if, say, you had an high-functioning autistic child who was fascinated by TV obstacle course shows. But that’s just fantasy, of course…

So, even if I don’t like Wipeout as much as the shows that inspired it, I think they’ve made excellent decisions adapting the concept of the obstacle course for the particular context in which the show has been launched. And it’s working. Last week, it was the number two show on US TV.


Hope this doesn’t count as an NDA violation, but I tried out the Clang Static Analyzer (as noted by Rogue Amoeba’s Quentin Carnicelli) on some of my iPhone projects and it does work, at least for finding simple stuff like Obj-C memory leaks. Very helpful, and potentially faster at finding the obvious bugs than the diagnostic approach of Instruments.

Journey Through the Secret Life of Phones

You would think that with the iPhone 3G’s release last Friday, the posting of iPhone OS 2.0, and the final release of the iPhone SDK… that between these events, the NDA that prohibited public discussion of the SDK would be lifted.

And you would be wrong.

Apple has told publishers — including but not limited to the Prags, who are publishing the iPhone book that I’m working on — that the NDA was not lifted on Friday. And that they’re still working it out.

Ergo, despite having lots to say here and elsewhere about iPhone SDK details, I’m still sitting on my hands. Maybe I should start just banging out drafts in TextMate while the ideas are fresh, and mass-post them later when the NDA drops. If it drops. Yeah, it would be crazy to stay NDA indefinitely, but we’re already in CloudCuckooLand to be upholding an NDA on an SDK downloaded by over a quarter million developers worldwide.

Bill, Marcel, and I did do an interview last night with Late Night Cocoa, which summarized the major APIs of the iPhone SDK and gave our impressions of the development environment. Even edited down, it’s going to be a long episode, and at any rate, it’s going to be on the shelf until the NDA drops. Alas.

The App Store is, perhaps as expected, a highly mixed bag. Along with really slick apps — I’m very impressed with the Pandora Radio client, and will be buying Starmap before we head up to the woods of Northern Michigan next week — there is quite a bit of abject junk. You’ve probably noticed the hundreds of public domain books wrapped by a one-dollar reader app (as if users couldn’t just hit Project Gutenberg with Safari), the appallingly trivial game apps (perhaps ported to Obj-C from the original Fortran listings in Creative Computing… I’m looking at you, Handy Randy), and four different versions of an iPhone “flashlight” (i.e., a completely white screen, thereby turning your iPhone into a de facto flashlight). On the latter point, I’m sure that the one from Erica Sadun is good-natured and offered with the best intentions, since she’s one of the pioneers of third-party iPhone app development. But the other ones that cost a buck each… not so much. In fact, I believe this app requires no code and not even any work in IB: showing a blank view is kind of, well, default behavior.

By opening things up wide to all would-be developers, the App Store has the flavor of the podcasts directory: a wide variety of subjects and an equally large large variance of quality. Consider that the podcasts range from professional-quality audio and video to a kid in his basement talking into his laptop’s internal mic about how cool last week’s Naruto was. The App Store has pretty much the same jewels-and-junk mix, with the key difference that nearly all podcasts are free, while only a minority of the apps are.

I’ll admit — I had expected the initial app quality level to be higher overall than it’s turned out to be. Some of these apps could be written in a day, and might have been. The apps I’ve planned to do — once I get time away from editing and writing the book — are more ambitious than most of these (thnk “mobile podcast editing suite”, not frickin’ Nim), and now I’m wondering if I should take a shot at writing a simple app in a day, posting it, and seeing if anyone bites.

In fact, some of the paid apps duplicate programming examples we have in the book, like the generic shopping list app, a simple version of which I created as the example of using the SQLite database. So one thought I’ve discussed with our editor is that we might put one or more of the book examples on the app store for free, with an “about” link taking you to the book’s home page and the source. The pitch being: “Learn how to write apps like this!”

Of course, we can’t do that until the NDA drops. Tick, tick, tick.

My trash is leet

Oh look, my Mail trash is leet:

1337/leet mail trash

Yeah, I know, why would I only trash my leet messages? Heh…

Got a wish: Square Enix developing for iPod

In an O’Reilly blog a while back, I mentioned my hopes for iPhone gaming, given the suitability of the device for certain kinds of games (such as using the touch UI for menu-based RPGs), and Apple’s success in attracting great developers to its existing iPod game program, like Sega and Harmonix.

Add Square Enix to the list, who’ve just released the iPod game Song Summoner, an RPG in which you create NPC allies from the songs on your iPod, and level them up by listening to those songs (shades of the “generate monsters from CDs” gimmick in Tecmo’s Monster Rancher series).

Is it any good? We’ll find out when the download’s done:

Downloading Square Enix's Song Summoner from iTunes

More importantly, maybe we’ll get the inevitable modern-graphics do-over of Final Fantasy VII on the iPhone?

Java Video: Past the Point of Caring

I used to care about Java video (c.f., parts I, II, and III of an ONJava blog series about it). I don’t anymore.

It’s not just the shifting of my interest to the iPhone, it’s that Java’s powers that be have chosen their way, and it’s not something I think will work. No, change that: it won’t achieve any of the things that I care about. It may achieve the things they care about. Which, frankly, is demoing well at JavaOne.

At this year’s show, Sun announced they’d licensed some On2 codec, and showed off a “video cloud” demo of dozens of videos being played on panels being rotated about a 3D space.

People who don’t know better were impressed. Which is the point. What Sun needed to show was that it heard the concerns of Java developers about how badly the platform has lagged in multimedia support, and by showing a gee-whiz video tech demo, they mollified that crowd somewhat. Of course, this crowd of developers assumes it understands media because they all have iPods and have watched YouTube. it’s sort of like me presuming to be a security expert because I remember passwords and use login screens.

Problem is, as the problem always is with Java, Sun is talking to the customers they already have. Their solution is targeted to the developers already using Java. Were they talking to media application developers? Probably not, because their solution lacks credibility to anyone who actually works in the field.

Here, in a nutshell, is the problem. By choosing a non-standard video codec, they opt out of the economies and ecosystems that have developed around mainstream codecs like H.264 and VC-1. With the MPEG standards, for example, there is competition among encoders, as only decoding is standardized. Any product or process that produces a compliant bitstream is fair game. As a result, the bitrates needed to produce broadcast quality MPEG-2 dropped from 8 Mbps in the late 90’s to about 2-3 Mbps in the last few years. H.264 is expected to see the same evolution, driven by competition between encoders. With a single On2 encoder, Java Media Components won’t enjoy this kind of improvement. The no-brand codec also opts out of compressionist expertise.

And there’s also the question of whether the encoder is appropriate for multiple purposes, as H.264 has proven to be (albeit with so many optional features that the different profiles might well have been different codecs in another era). To my way of thinking, you generally need three functional styles of codecs, which often requires three totally different codecs:

  • One-to-many playback – cases where the content is encoded once, and played back many times. The encoding may be thought of as “asynchronous”, in that the encoding may require much more time, CPU power, compressionist expertise, etc., than the playback. Example: DVD.
  • One-to-one telephony – cases where encoder and player are more or less equals, needing a codec that can be encoded and decoded with the same resources (CPU power, time, etc.). Example: video conferencing
  • Production – cases where the content will be heavily edited and processed. Codec here needs to be scrubbable, be easy to effect and edit, not be subject to generation loss, etc.

In general, I don’t think you find one codec that does all of these things well, and the fact that you see H.264 used for both playback and videoconferencing may speak to its high level of configurability. Presumably, you’re not using B-frames for video conferencing, due to the compression-time expense and the introduction of latency.

So having said all this, the idea that one codec is going to take care of all Java Media needs is highly implausible, especially since it’s not H.264.

The other thing that’s a big gotcha with Java Media is that the HTML5 <video> tag is poised to utterly commoditize media playback anyways. Why endure the hassle of trying to get Java runtimes on end-user systems, or have your developers and designers master JavaFX, when legions of JavaScript-savvy Ajax developers are getting video support provided to them with an industry-standard tag? Even if <video> doesn’t end up with a de jure official codec, it’s highly likely that H.264 will fill that role, as browser makers can rely on QuickTime and Flash, among other libraries, to render it. And if not, the prospect of browser-sniffing and sending different <video> tags to different browsers may still be more appealing than trying to goad users into installing Java.

To the Java crowd, this looks like a perfectly reasonable way to bring modern media support for the platform. It won’t matter, and they probably won’t think to ask why.


iPhone book has gone to an internal review which, should it be accepted, gets us to a beta book soon. Really soon. There are many chapters from the three authors in various states of completion. As things split, three of my initial four were ready for inclusion, so of the 102 pages in this early build, I wrote 50 of them. Which is damned strange considering that early on, I was the silent and unproductive member of the team (during and immediately after one of our house-shopping trips up to Grand Rapids).

File I/O, Preferences, and SQLite are in the can, Network’s getting there (though I’ve bogged for two days on various crashes I created after having to switch an in-memory cache from Cocoa’s NSDictionary to Core Foundation’s CFDictionaryRef… figured out Tuesday’s, now I’m on to one a few functions later). Apple rejected a feature request I sent in regarding the techniques of determining your network interface, but did so with interesting comments, so that’ll make a good topic to wrap the network chapter with.

Media’s after that, and that’ll probably be a couple weeks of heads-down coding to finally make Audio Toolbox happy (for a change) and OpenAL. And after that, I’d have five of 17 chapters done and presumably be able to see the finish line. Not a bad crunch overall… and the project’s velocity has definitely been kicked into high gear with the addition of Bill Dudney, whose enthusiasm and productivity are inspiring.

Don’t know if they’ll put out a sample chapter, but I’d nominate the SQLite one, actually. Apple’s docs basically say “you have a database, here’s its home page, go nuts,” so the stuff I wrote couldn’t help but be new and novel and tell you stuff that isn’t in Apple’s docs.

No official announcement of the book yet, but there was a sly reference in the latest newsletter (though one could interpret that as a reference to the iPhone material in Bill’s Core Animation book. Of course, we know better…